I'm guessing the issue with infected machines on a guest network is that they could infect other guest computers.
Within the SSID settings, you can also expand DoS and prevention filters,
then click the + button on Traffic Filter,
Uncheck 'inter-station traffic'
You can also remap the windows XP users to a vlan that doesn't exist through client classification policy within the User Profile.
A laptop, phone etc doesn't tell the AP "I'm Running XYZ OS" we pick up that info either through the DHCP hand shake (after authentication) or through HTTP User Agent strings, also after auth. So unless these are XP machines in your own network which you have control over to use group policy to prevent them from connecting wirelessly, it's not possible today.
You can remap them to a User Profile with a VLAN that doesn't exist. AFTER authentication. So the effect is essentially the same. Apply a Firewall to that User Profile that drops all traffic.
There are Third party NAC type devices out there that can achieve this. They typically disconnect unapproved devices by sending an SNMP or SSH command to the AP to block the MAC and deauth / ban the user. (However, this happens after auth/association as well)
Having a default VLAN to nowhere would be best practice, but it would be nice if a user profile can be created for OS's (since Aerohive picks it up in HM). The response does address the issue however.
Jeremy - You can have a user profile for OS's ... This is what I was trying to explain in the post above.
Go into any DEFAULT User Profile and expand "Client Classification Policy" - Check the box to enable remapping based off of Client Classification. Then create rules, based off OS, MAC address, Domain Membership etc. and which User Profile they should be remapped to. (User Profiles also contain VLAN information, so it can effectively change their VLAN as well)
This does require you to be using an external RADIUS server that is configurable in this way.
If you are using NPS, you control this via SCHANNEL configuration in registry: http://support.microsoft.com/kb/245030/en-us
Note, there is an undocumented change from Server 2008 onwards that applies here, the "Triple DES 168/168" key became "Triple DES 168".