This could be implemented as a custom filesystem. Generalizing it to all components would be virtually impossible, but making for instance a "redstone filesystem" wouldn't be too hard.

...In fact, I'm going to go write that right now.

Place this in /bin and this in /lib, run mount.redfs /red and voilà. It only does redstone and it's somewhat hideous on the inside, but it hopefully makes a usable starting point if someone wants to make a full-on /dev filesystem. (If anyone does use this as a starting point, please generate your own UUID to use as the address.)

Great, thank you. That works precisely what I had in mind for the redstone.

For my use case I would have to have also bundled cable support. This way it would make full support for redstone.

Would you be willing to add that? BTW I would really like to see that mount.redfs in OpenOS by default. Because it is perfect.

With a bit of cleanup (which I'm mostly saying because SolraBizna declared "it's somewhat hideous on the inside") I'd happily accept a PR with this on a loot disk. Or make it available via OPPM. Or both.
One thing that might make sense is to pull out the monkey-patched component.proxy and include that functionality in OpenOS itself (to avoid each fake component having to patch the already three times patched method...), with something like component.addProxy(...)?
Either way, make a PR if you like.

I didn't include bundled cable support because I don't have any bundled cable mods. Are there any mods that add bundled cable and little else?

For example I'm using ProjectRed (it also adds some gates, lamps and lots of other stuff), but there are probably others too. In my oppinion bundled cables are one of the most impotant additions to minecraft wiring and especially if you want to controll whole base from single point (ie. computers).

I uploaded a new version in OPPM-friendly format here. OpenComputers 1.4.7 is now required, as the new version no longer monkey-patches component.proxy. It has been significantly cleaned up, and now uses an internal tree instead of hardcoded path resolution logic (ick). Still largely free of comments though.

This version is a much better starting point for other custom filesystems; the component-simulating code itself can even be used without modification as long as your custom filesystem's tree fits entirely in memory. (Again, if you do use this as a base for your own fileystem, generate your own UUID.)

As for bundled redstone and wireless redstone... I'm reluctant to add another mod to my list. However, I did include an attempt at support for wireless and bundled redstone. It has not been tested, but it may work. If it does, .../(card)/wireless and/or .../(card)/(side)/bundled will exist for tier 2 redstone cards. If not... let me know and I'll do my best to fix it, but I make no guarantees.

@SolraBizna, if you want I can add your github repo to OPPM, you'd just need to actually fix the programs.cfg file (line 11 should be changed to repo="tree/master/redfs",) and tell me :)
Alternatively, you could also migrate it to OpenPrograms if you want to. You should only do this if you are pretty sure your package is fine for others to use (i.e. doesn't break everything).

Fixed programs.cfg. Assuming it works at all, redfs's capacity to break other parts of the system is pretty limited. As for adding to OPPM, that's fine with me. As for OpenPrograms, I'm not at all sure what that would entail. All this newfangled git stuff is confusing to a graybeard like me... :P

If I understand correctly this is / will be available via OPPM, so I'll be closing this.

@SolraBizna Your repo is on OPPM now.