Anything is possible. It depends if you want to hack it into the editor or collaborate on a more considered approach that is extensible for others beyond just your use case.
The hardest part, which I don't see you being able to do from your node's own code, is the layering - having your node below all others. You cannot control what layer nodes are drawn in - so you'd need to modify the editor to ensure your node is put on a new layer under the existing node layer. That then makes this a bespoke version of the editor for your use case.
As I said in my original reply, I'm focussed on 1.0. One of the breaking changes it introduces is a complete rework of all of the CSS styles and DOM element IDs throughout the editor. Any nodes that have hacked their appearance in the editor (such as the Image Viewer node) will be broken in 1.0. This is why we have never supported nodes hacking their appearance - we knew we wanted to make these changes and didn't want to have our hands tied.
Equally, once we have got to v1.0 and these changes made, we can begin to consider what extension points we could/should expose in the editor and what other drawing tools/layout options we could provide. If we can support some of these things through an abstraction API without nodes having to hack the dom, it gives us more flexibility to change the internals without breaking these nodes in the future.
Being able to group nodes is something I've looked at before - in fact there are some remnants of those experiments in the code today. The UX was hard to get right and ultimately wasn't worth the effort at the time. But it is something I'd like to eventually revisit.
Having more people interested in working on this would help. The problem is that people often just want to solve their own specific scenario and don't want to invest time in the more abstract design work. And that's why it doesn't happen until I have the time to do it.