On
To expand on nitzmahone's eexcellent points:
Completely replacing GINA is really a no-no using managed code. OTOH, it is quite possible to write a replacement GINA in C++ and have it call .Net code to do the grunt work.
Some years ago I used this technique to replace the CTRL+ALT+DEL screen with a fancy news service. My custom GINA was a proxy for the standard GINA. Most of the time it transparently passed calls on to the standard GINA. The exception was that it ran the .exe for the .Net app instead of displaying the ALT+DEL+CTRL screen, then waited for the .exe to terminate before displaying the logon screen.
With regret, I abandoned the project when it was clear that the work could not be directly applied to Vista.
Hosting .NET in Winlogon (where GINA dlls are loaded) is probably not such a hot idea- could cause all sorts of conflicts if something else decides to do the same thing, and if you trash winlogon, you're not getting anywhere with that PC. Also, GINA has been replaced as of Vista with ICredentialProvider (see here)- so your investment would be lost as soon as you move to a newer OS. Even there, the same thing applies: custom credential providers are loaded into Winlogon, so probably not a great idea to use .NET there.
Regardless, both of these are intended to support custom authentication modules, not "controlling what employees are doing". There are other ways to run software on the logon desktops, if that's what you're trying to do.
All that said, if you still want to try it, you'll need an unmanaged shim DLL, C++/CLI or some IL hacking (see here) to export the GINA functions because C# can't directly export DLL functions. A pure managed C# solution isn't possible.