Yes, this is still on the horizon but I'm not really clear on what it means yet. The cleanest way to create a widget would be to write a .vue file. A good non-trivial example is the implementation of the gauge widget. If you look at that, bear in mind that 95% of the work has to do with getting the SVG drawing to conform to the enclosing widget card and to position the title and value on top of that. I used vuetify classes for some of the text stuff but it may actually have been cleaner to use plain html and css. The rest is stuff you can learn in 10 minutes and is covered in the most basic Vue tutorials.
I believe such a Vue file could be authored using your favorite editor if it can save to the static file area of node-red or it could be authored directly in node-red given some of the functionality in uibuilder.
So there are a bunch of things you're touching on. The "single general node" thing is a uibuilder concept. For FlexDash it's really "a single topic tree". I have not yet gotten to writing node-red nodes for FlexDash, but so far my experiments tell me that one single node is usable but not so great.
On the output side (from NR to FlexDash) there are a number of things that need to be done, two of which are assigning a topic to messages that don't have one and sending the last remembered value to new browsers connecting. On the input (from FlexDash) one has to filter the topics and only forward the pertinent messages. All this can be done with conventional NR nodes but this is how my test flow looks like and I only have a couple of topics:
My thinking is that I would like to have a couple of nodes that cover a few output and input use-cases using single nodes without links or anything. So if you have a node that outputs a message with a payload you can drag in a flexdash node, wire one into the other and set the topic on the flexdash node and be done. This is very similar to the way the UI nodes work, except that you decide which widget displays that value in flexdash not in node-red.
(Hmm, some crazy thoughts come to mind, such as loading a portion of flexdash showing the widget and the edit panel into an iframe in the NR editor...)
In terms of "installing" that's still entirely open. Most likely widgets can be installed by dropping some files into a static web server directory (node-red provides one). That means that in principle, you could install a node-red-contrib-xxx package that all it does is drop some files into the right directory. Not sure how the user experience ends up looking like... With FlexDash it might even be possible to load widgets without any installation, just by typing a URL and asking it to load that. I think it's too early to determine what is going to work for people and what not.
In terms of configuring, FlexDash deliberately differs from the way it currently works in node-red. Take the example of configuring the colors and thresholds of a gauge (oops, I haven't really implemented the the color thresholds yet, so this is a bit forward-looking). In NR you do the config in a panel, then you deploy, then you switch to the dashboard, if you're lucky it's showing the effect, often I have to refresh and wait, then you don't quite like it and repeat. In FlexDash you click on the edit pencil on the widget, then as you click on a color in the color picker the widget instantaneously shows the effect. If you want to see how it looks with 95 as input value, the moment you type "95" into the input box you see how that is rendered. So the feedback is instantaneous, no "edit-deploy-refresh" type of cycle. That being said, I'm sure some people will prefer the current way 
.
Given that FlexDash barely exists it's a bit early to think about migration 
and I really haven't spent time thinking about it. I believe there are a number of different options but they're all very speculative at this point.
Thanks for chiming in!
