It should be possible, but if you don't know any C++ then it might take a bit of investigation to work out how to translate the structures and DLL functions you need to work with into C#. I'll be like using P/Invoke stuff to call Win32 APIs.
It could result in problems, though... Hosting .Net within a native process which doesn't know anything about it is fine until two things try to do it. Then those two things can conflict with each other over things like which version of the .Net runtime is loaded. This is one of the reasons why it's not a good idea to write Explorer shell extensions in .Net.
That doesn't mean you can't do it, though... It just means there could be complications down the road. They're complications that could be solved, though.
If there is demand for a .Net plugin API then that could be provided as well, and it could be done in a way which avoids the potential conflicts. (e.g. By running the .Net code in a separate process which Opus creates to provide the plugin with the .Net version and environment which it specifies, and which the plugin author doesn't have to worry about.)
I think you're the first person to ask about .Net plugin writing but I don't know if that's because nobody is interested in it, or if there are people who might want to write plugins in .Net but see there isn't an API so haven't taken things further.
Personally, I've been looking for a good excuse to try writing a .Net plugin and experimenting with some kind of .Net wrapper for the plugin API for a while now, but everything I've done so far has been naturally suited to C++ (due to using a lot of Win32 native APIs or C++ library code).