Ok, I have since then found the necessary procedures myself.
Therefore I will conclude this thread with a short writeup of my findings. That is, unless your experience differs or if some of my findings aren't correct. In that case please do reply!
The InView Editor is in fact handled as a manipulator, but there is no functionset for it. Here's what I found:
Setup:
1) Create a Manipulator plugin using MPxManipContainer
Manipulators can either be applied to a plugin context or to a node.
2) Give your Manipulator the name of the nodetype it should show alongside to, appended by "Manip" (important)
3) Call "MPxManipContainer.addToManipConnectTable()" in the node initialize, where you declare your plugs.
(also make sure to use "removeFromManipConnectTable()" when unloading your plugin)
4) Inside the MPxManipContainers "connectToDependNode()" method, use "addPlugToInViewEditor()" on any plug of the selected node, given it's the one you want.
(It doesn't matter which plug, since the inview editor will at that point show up for all keyable/channelbox attrs)
5) No further setup steps, like you would usually have for other manips
6) in the case of a polycmd, after you're done commanding, select your node and set the context to "ShowManips"
Limitations: (Assumed)
- After some research and from my own experience, MPxManipContainer is currently practically not usable in python api 2.0, so if you're using api2, a separate plugin file has to be created for the manip, written in api1 or c++. A py2 Node can interact with such a manipulator just fine, which was what I had tested.
- There is no control over the order and visibilty of attributes on this plugin iv-editor. The only thing that controls if an attribute shows is if that attribute was keyable/shown in the channelbox. The menu to hide/show attributes shows up, but the settings do not persist and there is no way to catch those changes, so even if there was some file in the prefs that dictated what shows, it would be a very manual process regardless.
- The tab hotkeys to switch between attributes as well as control via mel/cmds' showManipCtx() is not supported
- Selecting an object together with activating the required "showManips" context usually picks up the manipulator of the latest modifiercmd node by itself. In this case, however, the node has to be selected specifically via the node editor or the channelbox(for a polycmdmod). A combination of callbacks could be used to mirror the default behaviour, which I think would be too intrusive.
Conclusion:
Now, I have only used an api1 manipulator with an api2 node, so I can't say if things are different for a c++ implementation, or other possible configurations, but unless someone has some other information,
I think it's fair to say that the current api implemention of the in view editor simply has too many limitations/differences compared to the expected user experience.
Personally I will stick to a custom approach