no, you are right. of course there are dark magic workarounds:
embed a signed java applet. if the user accepts the certifficate, it has virtually any permission. bind a port and use it for communication between flash and java (over TCP). be sure to respond to the policy file request, otherwise flash will automatically close the connection.
get a DNS server. when user opens a session, generate a subdomain, such as sessionID.yourdomain.tl with an extremely short TTL, that maps to your own server. the first request will be for an additional SWF file, the "proxy". after that request, remap the subdomain to the google server. the flash player is thus tricked into perceiving the proxy and the target API as having the same origin. be sure the proxy allows access from the container and create a little interface that allows you app to issue URL requests through the proxy.
edit:
well the first approach is actually feasible: http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/rsa_signing.html . i suppose it is easier to implement a lightweight TCP protocoll between java and flash, but an alternative would be to make flash->java communication HTTP based. Don't know if there are any libraries for handling HTTP requests in java.
as for the second approach, you can use BIND with DLZ. once you have it up and running, altering the DB should suffice.
none the less having an intermediary server is the safest solution. although you may wanna consider that some of google's APIs are limited per key per day per IP. you should check this to avoid problems. a few years ago we ran into this while using Google's APIs for geocoding.
greetz
back2dos