The private key is the distinctive power of each machine. Having distinct keys for the machine makes sense, from a security point of view, only if the machines are not equivalent to each other. As you note, if an attacker obtains full control of one machine, then it can spy on the network and observe the files of all other machines, including their SSH private keys. It could also simulate the bootup procedure of any other machine, using the MAC address for that machine at the BOOTP/DHCP/whatever stage, and obtain all the secret values of that other machine. In short words, hijacking one machine can easily be expanded into hijack of all the machines. In that context, per-machine private keys would not buy you anything more.
If you want better security, including some isolation layer which would make machines not equivalent to each other, then you will need some heavy artillery. NFS is built over RPC, and there is an extension called Secure RPC which allows for encryption of all the data; however, it is old, poorly supported (I am not sure Linux supports it, for instance), and poorly maintained (if at all). A newer and arguably better method would be IPsec. Alternatively, one can encapsulate the NFS traffic into SSH, as explained in section 6.4 of this document. This raises interesting chicken-and-egg questions: how do you setup some SSH (or IPsec) in order to tunnel NFS in it, if you already need the NFS to obtain the SSH (or IPsec) private key ?
This is a rather generic point. Diskless systems are diskless. As such, they are, when shut down, identical to each other. Since a diskless machine cannot permanently store anything, it cannot contain any secret value which would give it some power denied from other machines. Consequently, all the diskless systems can be "emulated" from other diskless systems, in the bootup procedure, as alluded to in the first paragraph. Therefore, you cannot really create a context where the diskless machines would be really distinct from each other; as a corollary, you don't need to make the SSH private keys distinct.
Some notes, though:
If you can arrange for each diskless machine to have some local storage, e.g. a SD card on which it boots up, then you can put machine-specific secret values in there; and then you can have per-machine SSH private keys. Simply, the private key is read from the SD card, not from NFS, and private keys cease to travel unprotected on the wire (they cease to travel at all, which is even better).
Theoretically, you can get replace such local storage with human storage: arrange it so that a trusted sysadmin presides at each bootup, and enters a long secret password in order to unlock the machine secrets. I am not aware of existing software which would allow that, but there is no conceptual limitation. Except, of course, the need for the physical presence of a sysadmin every time a machine must boot or reboot, which is likely to be an unbearable constraint.
Don't put too much trust in VLAN. There are several protocols for that (standard and proprietary), but most are unprotected: frames are tagged by switches so that they know whether a frame should be shown on a specific wire or not. If an attacker gets physical access to one of the switches, or to a wire connecting two switches together or one of the VLAN-able machines to a switch, then he will get full access to the VLAN contents.
These are students. Compromise of a machine at some point is a certainty. One of them will unplug a machine, plug his own laptop in its place, configure the laptop to assume the IP and MAC addresses of the unplugged machine, and read all the files. This is easily done, in less than a minute, with generic OS tools. This goes a long way to say that if the students are attackers, then you are doomed. You can try to deter them with physical shielding (don't leave wires accessible in any way) and threats (trespassers will be beheaded and their corpses put on display), but this won't ultimately work. A better method, that I saw employed with success, is empowerment: monitor things so that you identify students who seem to be interested in security, and give them official admin power. They will not hack into machines that they already have root access to; and you can make them co-responsible for security, so they will cooperate in tracking trespassers.
A very common method for security is not caring. Just let the diskless stations become a godless wilderness, and filter things at the periphery. Students are creative and prone to test security, but they also get bored pretty quickly. Whether that method is good is an open question, but at least it is very easy to implement.
