First, this sounds like something you will have to troubleshoot with Amazon. A simple tracert to your destination host will show you where the delay is.
Second, you should design your application to load the page and then display the data whenever it becomes available, not simply expect it to show up. It sounds to me like you have not utilized any AJAX failover in your application. How can you be sure that your new application will ALWAYS have a connection back to your legacy app.
TL;DR: Run a tracert, call Amazon, check your code, make sure it allows for delays and no internet connection scenarios.
Firstly, it's important to recognise that the DNS records cached on the client or their DNS resolver which are both out of your control (note that I'm referring to the DNS records not your authoritative name server). Therefore it's up the client and their DNS resolver to honour your TTL.
In the case of a new visitor who has never visited your site before and whose DNS resolver has not cached your records (or visited long enough ago that the cache has expired) they will see the new records immediately.
Shouldn't this be under 60 seconds?
It should, but that's only if your client honours the TTL. Some clients have minimum TTL's and some networks also have a DNS resolver which may be caching results.
Is it possible to reduce this time?
You have to remember that the majority of your visitors (assuming this is a public site) won't have been sitting there loading your site every few seconds like you have. Most of your visitors probably won't have visited the site recently and and their DNS resolver may not have the records in their cache. Most DNS resolvers should respect your TTL but you can't guarantee this.
What is a safe time to delete the old stack?
You're better off judging this by what traffic is still being served by the old stack rather than DNS TTL. If you're using ELB you should be able to view how many requests per second are being served by the old ELB in cloudwatch. Wait until this drops below an acceptable level then delete it.
For the sake of viewing the new stack immediately after the switch I recommend just manually flushing your local DNS cache. Leaving your own client to expire records naturally for the sake of seeing how long it takes probably won't be indicative of how long it takes for other clients.
Edit, I noticed Google's Public DNS has a tool to let you flush the cache:
https://developers.google.com/speed/public-dns/cache
This may speed things up as a significant proportion of clients are likely to be using this.
Best Answer
Interesting question - it doesn't appear to be explicitly documented whether Amazon Route 53 supports IP addresses outside of the published Amazon EC2 Public IP Ranges, but I think it does to some extend, here's what I've figured/tested:
Documentation
The introductory blog post Multi-Region Latency Based Routing now Available for AWS mentions that If you enter an EC2 instance public IP, Elastic IP, or Elastic Load Balancer target in the Route 53 console it will suggest the correct region for you - This is indeed the case, while entering a non EC2 IP address leaves this selection up to you, see Tests below. The post also states the following:
Furthermore, the post mentions that Latency Based Routing is available for the "A", "AAAA", "CNAME", "TXT" DNS record types as well [...].
Test
With the above background information I've created a latency based resource record set with EC2 instances us-east-1, us-west-2, ap-southeast-1, ap-southeast-2 and added a non AWS router/gateway of ours in Europe, specifying eu-west-1 as region accordingly.
I've used a low TTL and included/excluded and cross tested the respective DNS responses from these four instances and Route 53 delivered the desired result indeed, i.e. responding with the non AWS IP address in eu-west-1 where appropriate and depending on which regions have been included in the set.
Conclusion
Latency based routing to non AWS IP addresses seems to work to the extend that you need to subsume your own addresses to one of the available AWS regions - this does make sense, insofar AWS needs to employ latency measurements for non AWS routes anyway to achieve the desired shortest path analysis from an end user perspective and these systems are mostly running outside of AWS.