Here's one way: User Roles in Browser-Enabled InfoPath Forms
I also have a 2nd version of this same blog that leverages Active Directory groups instead of a Contacts list. I'm almost done, but I keep getting distracted from it. It leverages the built-in GetCommonMemberships web method of the UserProfileService that is exposed by the SSP in MOSS (not available in WSS 3.0).
In terms of code, I'm sure you could write something, but it would much more time-consuming and customized than the solutions I'm proposing. However, I don't write code in my solutions, so one of the great Qdabra folks here may say otherwise.
As for preventing other users from opening existing forms, you can't easily do it with SP permissions, but you can do it pretty easily within the form itself by switching to a read-only view on form load based on the user's "credentials" (profile info) or based off the status of the form itself. This doesn't disallow tampering of the XML directly if they choose to do that, but it would keep them from modifying the XML with InfoPath. If you need 100% security, you either have to do it manually (edit permissions on each item) or with code that sets permissions dynamically.