So far, I see lots of advice about VM breakouts and network isolation. If this were a production datacenter where uptime was a criteria, this is all well and good. I suspect that this isn't what you need to hear, however.

I see three things you could be attempting to protect:

1) The larger school network.
2) The VM host infrastructure.
3) The VMs themselves.

1) A student on a VM is no more dangerous to the network than one who can connect to the school wireless with a laptop or smartphone. If the lab uplinks to the same network as the broader access, your risk profile is unchanged.

2) Make sure the VMs can't route to the host and keep it patched. If a student managed to break out of a VM in a patched hosting environment, do some forensics and find the bug then sell it. It's probably worth more than you make in a year. Seriously, if they can do this, they deserve to win. You might as well worry about protecting against nation-state sponsored attacks.

3) Make sure that the class work is backed up (a git server, perhaps) and then don't worry about it. Seriously, just throw the VMs away after each class (or every night, etc) and start with a clean one the next time they log in. Don't spend time trying to outsmart a classroom full of bored highschoolers. Instead, make it so it doesn't matter when they break something.

Really, if you're going for hacker, the invitation shouldn't just do something. Recipients should be able to do something with the invitation. Check out the Defcon Ninja Party invitations:

http://www.wired.com/threatlevel/2010/07/defcon-ninja-badge/

Any authenticated site should be doing this -- it's only a couple of lines of Javascript to reasonably cover your bases.

Why aren't you? Is there some sort of crazy business blocker?

Right, but individual passwords scavenged from login attempts -- individual data points -- are not nearly as valuable as the aggregate password tables.

Even is the attacker has root on the web application box, they shouldn't automatically get raw table access to the database backend (assuming that the database is on the back-end, and not on the same box as the web server). You should be using execute-only permissions on stored procedures to validate passwords in the DB, not performing a comparison on the application server.

I know it's bad form to link to oneself, but I have a reasonably thorough explanation here:

http://www.hackerco.de/hackercode/2010/01/secure-web-form-authentication-using-stored-produres.html

I think what you're looking for is the Open Web Application Security Project (OWASP) Guide:

http://www.owasp.org/index.php/Category:OWASP_Guide_Project

It's pretty much the industry standard.