Most DNS failover TTL's will be set to 30 seconds, allowing about a maximum 60 seconds outage for a sites IP address to stop being advertised to clients after the time it takes for your service check to mark a site "bad". Most DNS caches will obey TTLs, some don't. Some clients can cache IPs too (java!).
The "VIP" option you alluded to in your post of a single cloud load balancer(vip) does allow you to fail sites over more quickly as you can move traffic from site to site as soon as the service is marked bad. That does add a single point of failure though.
Load Balancers + DNS failover
| \ / |
| X |
| / \ |
If you have two cloud based load balancers (preferably in different sites, or different providers) and front them with DNS failover then you can move clients from SiteX to SiteN as soon as a failure is detected and also be protected in the off chance a load balancer goes down, which should be a lot less frequent than a virtual desktop service hosted over your office's net links.
There are other ways to achieve failover at the network level with BGP routing and BGP anycast, if you control your own IP ranges and have BGP routers. That sounds a bit above where you are aiming at?
For any failover to work well you need a thorough service check for the virtual desktop service to confirm a site is in fact working. I'm not sure how far you can check a virtual desktop beyond authentication unless you write a really nifty client. Maybe you could provide system metrics from your sites as well that might help indicate a site has "gone bad". These could probably come from the clustering you're doing inside a site as that will have to have a good idea about the status of the service.
Also, with multiple sites some consideration needs to go to where clients end up connecting to. Can they switch back and forth as often as they like. Is it better if they stay on the one path. Is active/passive a better way to go? Is geographic location a big factor? These are all very specific to what you're implementing. Always test what you think is best, and always test every failure scenario you can think of.