In retrospect, I guess I should've known. The answer is in two parts, because, in my mind, there's planned failover and "real"/unplanned failover---and planned failover doesn't count.
Planned failover
Planned failover is actually just the Clustering system draining the node, then rebooting it for you. So when you directly reboot the node via RDP or "Stop Cluster Service" in the Clustering app's GUI, the first thing that happens is the VMs get Live Migrated off. Because you're really just Live Migrating the VMs, the time it takes is dependent on what needs to be transfered, and the network connection. If you have a 1Gb NIC, it's going to take a while (~118MB/sec). The more RAM your VMs have, the better served you will be by faster NICs.
Real failover
Unplanned/"Real" failover is when you unplug the machine. In that case, the cluster system automatically starts the VM up on another node. The behavior to the outside world is the same as if you'd rebooted the VM. To the VM, it's the same as if you'd "turned it off" then started it again. So a "real" failover is always going to be about how long it takes your VMs to boot.
Tangent
This is a let-down to me, conceptually, because I feel like all the clustering talk on the 'Net suggests that a ("hard") node failure is hidden by the clustering system---it's supposed to be like the services never went down. It's likely propagated by the fact that all the web pages I remember reading tested their cluster failover in software (planned failover). So all they're really doing is proving that Live Migration works as advertised (no downtime from the perspective of the client).
My main mistake was misunderstanding failover itself. In addition to the concept of having a hot/warm/cold backup server, where automatic failover occurs on a hot server, there is also hot/warm/cold failover. As mentioned here, hot failover is instant, warm failover is measured in seconds, and cold failover is measured in minutes. I was naive to assume that all automatic failure is "hot". I guess I was expecting some sort of magic with the RAM where the cluster would update a copy of the VM's RAM on another node---something like transaction log shipping with Sql Server. But that would require a communication channel between machines that is at least as fast as RAM to guarantee it would work.