No, that's not advisable. For one, running virtualization on top of virtualization is going to perform poorly. And most developers don't like to work against a remotely hosted virtual machine, where every little operation has a bit of delay (due to ~50 - ~200 ms network latency).
The most common solution is something along these lines:
- Every developer works directly on his own local PC, and has a suite of dependencies installed as needed (Visual Studio, .NET, IIS Express, SQL Express, etc).
- Code is pushed to a central repository (Subversion, whatever).
- A Continuous Integration (CI) server (fx Hudson, TeamCity) checks out code from the repository, builds it, runs unit tests, and possibly installs it directly onto a Test or Staging server.
Your CI server, Test and Staging servers could happily live in the cloud (easier with something like Virtual Private Cloud). So could your code repository, but if you don't prefer it on-premises, then you should just outsource it to a hosted Subversion / Git service.
Edit: You could test it (that's one of the benefits of cloud computing -- you can spool up a server in a matter of minutes, and test how it actually performs for you). But how about running a Windows 2008 R2 server in-house, and setting up VMs on that server instead? Near-zero network latency, and not hard to do at all.
Before we go any further -- why don't you ask your developers how they're used to doing things, and what they prefer...