I think you're being penny-wise and pound-foolish.
First of all, machine costs are trivial compared to the cost of a developer. You should work at maximizing productivity, not minimizing machine cost.
Second, latency (not bandwidth) is the key to many programming tasks -- especially text editing. For every dollar/pound/euro you save on machines for your developers, you'll spend at least ten on network upgrades to maintain even a semblance of productivity -- and even then, they'd probably be more productive if you economized by supplying them with Pentium III's you found in a dumpster somewhere.
I also think there's a substantial benefit in having your developers use an environment at least reasonably close to that expected of the target end user. Regardless of official performance targets in a spec and such, most programmers base quite a bit on how the code "feels" when they test it. When they're using a completely different environment from the end user's, they're likely to waste time on trivialities while completely overlooking major problems.
As attractive as a homogeneous environment sounds from a viewpoint of support and such, you should generally encourage as much variety in the developers' machines as possible. Developers rarely need much support anyway, and knowing immediately when you have code that's going to fail with a different graphics chip, CPU, network adapter, etc., more than repays the minimal investment.
Bottom line: if you're writing code that's intended (at least primarily) to be used in a virtualized server environment, you just about need to provide that for your developers. If you're doing it anyway for testing, it can (but doesn't necessarily) make sense for development as well. Likewise, if you need (or at least have) a severely over-speced server and network anyway, it might make sense to take advantage of that by using what you already have available.
Under most typical circumstances, however, it seems to me that this is likely to introduce more problems than it solves.
