First attempt to migrate EC2 MySQL to Amazon RDS no going well - SUPER privileges

You do likely need log_bin_trust_function_creators = 1 on RDS but that isn't the issue, here.

You can specify a DEFINER value other than your own account only if you have the SUPER privilege.

^{— http://dev.mysql.com/doc/refman/5.6/en/stored-programs-security.html}

When a stored program (proc, function, event, or trigger) is running, everything it does has the permissions of the user who defined it, or of the user explicitly stated with a DEFINER declaration. This allows, among other things, for stored programs to permit other users to do things to data they don't directly have permission to manipulate, as long as they have permission to use the stored program itself.

It would be a serious vulnerability, then, if a non-SUPER user could create a procedure with an arbitrary definer, because the user could escalate his or her privileges at will.

This is also true of views, of course, when the definer security context is used, as in the example you posted.

One of the biggest complaints I have with RDS is that you can't have SUPER... and now it can be one of yours, too :) because that fact is the cause of the problem you are having.

Of course, if I were running a managed MySQL service, I wouldn't give anybody SUPER, either, so their security model makes sense, even if it is sometimes unwieldy.

If all of your objects have the same definer, a workaround would be to restore the dump using that account instead of the one you're using now, but that seems unlikely.

Deleting just the line with the DEFINER declaration should make the dumpfile work in cases where it appears on a line by itself, or you could use sed or perl to modify the file... an idea that I already know you're not fond of, but it really is a nice thing about MySQL that such hackery is quite legitimate, and not really all that far afield from the kinds of things I have to do as a DBA even in a non-RDS envirnoment.

perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < oldfile.sql > newfile.sql

...possibly not the answer you hoped for, but you could run that against your dumpfile and should end up with a slightly more usable file.