Yeah, you could do that, but you'd only want to do it for simple, non linked doors. Well, I say that, but linked doors would really only be a matter of filling in more fields manually.

Basically to do it, just look at the func_door code in doors.qc, and imagine that running on your info_notnull. Then manually set all the fields to the values they would get. So for instance set

touch door_touch
use door_use
...

Although touch is actually a bad example as you don't need it here. Add any sounds you want, assuming they're precached elsewhere. Don't set think or nextthink, as you need them to set up the model. Also, don't set SOLID_BSP or MOVETYPE_PUSH, the former for the obvious reason, and the latter since it assumes SOLID_BSP. MOVETYPE_NOCLIP should work fine although I've not tested this.

Since you can't use think, you won't get a call to LinkDoors, as I alluded to above. But you can use the same trick about imagining running the LinkDoors function on some entities that should be linked and then manually setting what you would get. This involves manually creating a chain of entities in the enemy field, but refering to each component in the door by it's entity number. Ouch. So don't do that unless you really have to, and even then, probably easier to start with real doors, run the map, dump the in game entity info into a text file, then convert the entities to info_notnull, feed this info in and recompile.

Skipping the LinkDoors function means you also don't get the automatically generated trigger that surrounds it to open it. The easy fix here is just make it so your "door" is triggered by a trigger_once or trigger_multiple so it doesn't matter. You'll also need to set the enemy and owner fields to be the door itself in the simple unlinked case - remember that these fields expect an entity number, not a targetname.

Looking at this bit of code has also given me another exciting idea, but I'm gonna work on it and post it in the new tricks thread. This assumes it pans out...