I would be getting ipv6 connectivity, adding an unknown AAAA record such as ipv6 or www6; but not www, and do as many comparative ipv4 vs ipv6 tracerouts from as many route servers as possible. Then you will have the data you need to actually make an informed decision rather than just guessing how it will behave. Remove the temp record and add a real quad for www only if you liked what you saw.
I assume the name servers are also available over ipv6 including glue?
Why do you even need a AAAA record to do that? Just do a traceroute to the v6 address. The temporary AAAA record seems to do nothing useful in your proposed procedure. Easiest hack to test site usability: Modify your hosts file. Don't even publish the record in DNS until you're ready. Then there's no SEO implications. :)
So far the consensus is to run dual stack natively.
While this definitely is the way things should be set up in the end, I can see some valid reasons to run ipv4 and ipv6 on separate domains for a while before final configuration. For example, if I'm in an area with poor ipv6 connectivity I'd like to be given the option of explicitly going to an ipv4 site vs the ipv6 version.
I'd also like to not damage SEO in the process though. ;-)
If you're going to expose the site via a separate hostname (v6.bobdole.com), create a v6.robots.txt file that tells Google not to index v6.bobdole.com. Use an .htaccess rule to rewrite requests for robots.txt based on the host header, so v4 requests get the v4.robots.txt, and v6 requests get the v6.robots.txt, which tells Google not to index things. Nathan