Dearest Pony Lord;
As a paranoid KVM user and moderately long-term customer of yours, I'm one of those folks advocating turning off VNC after you're done with it and only turning it on as needed. As security conscious as your team seems to be, I'm sure you've got some monitoring in place to prevent brute force attempts on VNC ports, but still, they are vulnerable. It wouldn't be so bad if VNC didn't silently truncate your passwords to 8 characters, or send them with one of the weakest crypto schemes ever, as well as plaintext key events and absolute mouse posi.... you get the idea, it's an insecure pile of horse manure if you can get the right logging window in tcpdump.
That being said, my answer to your question is "It really depends". If you have a fantastic VNC/console implementation in HTML5/ajax, then for sure, this will help a lot. I will pretty much use the manage page exclusively and I'll set up the IP lock you'd implement. If it's crap, nobody is going to use it anyway, so it's not going to help a lick. I have a couple of concerns that this centralizes the point of failure to your Stallion2 server in both a security sense--comp'd stallion2 would mean free reign to everyone's goodies, a situation not much different than it is now; and a reliability sense--a failure of your LV or CN networks would make all KVMs unreachable via VNC console, as opposed to just LV on fail there, or nobody, if just CN dropped out. That being said, for most users the feature you propose would be be a fair step up in security in a way that is nearly transparent to users which is pretty much win/win.
If you're going to implement firewall IP locks for VNC however, I would really appreciate it if you implemented a full IP ACL solution, which is not too much further away, though I will be the first to admit the increase in complexity is not trivial. If I could lock to specific IPs, I'd be much more willing to leave VNC running, just in case. The way I handle security now is two faceted. First, at both of your locations I have a single VPN server on a 128 (used to be just ssh port forward, that works equally well) that I use to manage my machines at each site, still using external IPs since I don't know the VLAN IPs for the host nodes. Not that it matters, at that point the traffic is as secure as your LAN is, which is about the same as running VNC from Stallion2. Second, on any KVM which has data I think should be moderately secure, I'm running key-only ssh-unlocked FDE (not console unlockable). Debian 6 & 7 have made that setup extremely simple so there's no longer any reason not to and it's a lot easier to type my boot-server alias and type in the ssh key's passphrase than it is to vnc, etc. Foolproof, it is not, but it's the best I can do with the tools I've got. Having an encrypted FS is about making yourself a less easy target than your VM neighbor, hopefully giving me enough time to notice something is up.
tl;dr: You should do it, and it should default to "Locked to Stallion2". Please add VNC IP ACLs to your someday-TODO list as well.
best regards,
-tw