A few things to note about this setup:
1) If the customer has users using two-step verification on their google accounts, each user will have to make an application-specific password in their google account, and use that as their WiFi password, which more or less defeats the SSO angle.
2) Check that all the customer's devices support EAP-TTLS. Probably won't be a problem, but the slightly more common EAP-PEAP won't work due to the way MSCHAP generates keying material.
3) Check the customer's security requirements. They have to not mind that the service providing the RADIUS gateway into google apps will know their 802.1x send/receive initial keys. If they are not using two-step, they have to not mind that the RADIUS gateway provider will know their google password. Also the 802.1x initial keys are only protected by an MD5 hashing scheme, but I'm guessing if they are using google apps they are not going to be concerned about crypto requirements to that level.
Having support directly in an in-house CPPM would help alleviate #3, but might hinge on a B2B arrangement between Google and Aruba.to help ensure the usual Google rug-pulling doesn't happen.