It's generic in the way that it's aircraft-agnostic, as is exemplified by being provided via the built-GUI (see the debug menu in-sim).
However, it can be trivially added "as is" to any aircraft at the mere cost of providing the corresponding 3D models (which I believe www2 offered to do a few days ago).
That being said, Stuart is prototyping the whole thing using the c172p as reference aircraft - which is to say that there are going to be certain c172p related assumption (think number of engines, availability of systems etc) - but that is not to say that this cannot be changed, Stuart is using a combination of Richard's MFD/Emesary frameworks, which means that there is a clear separation in place, so that aircraft developers can easily adapt the integration layer for their own aircraft to make the whole thing work there - even though some adjustments may still be needed/beneficial.
Regarding your other questions, Richard's recent postings relating to Emesary suggest that he is in the process of of refining the MP protocol to better support the Emesary use-case/integration, while also considering to provide a native C++/Nasal bridge (probably using TheTom's cppbind framework) - conceptually, this could obviously be considered the "groundwork" to solve long-standing challenges that are commonly perceived to belong into the HLA/RTI department (think dual-control and other multi-instance setups).
Speaking realistically however, features like dual-control and the hard-coded master/slave protocols are dating back years, and even decades ago (in the case of the master/slave protocol) - which means that might be more straightforward to start afresh using "just" Emesary instead of adapting existing features to make them work with Emesary, because existing features like AndersG's dual-control framework were basically created in response to hard-coded restrictions, i.e. to work around those - thus, their design/nature and underlying operating mode is likely to be affected by those design constraints, which are unlikely to be an issue when it comes to Emesary.
As things are standing right now, it seems that the FG1000 is very likely to become the "reference implementation" for anybody considering to implement modern MFD-style avionics in FlightGear in a generic fashion using the Nasal/Canvas systems and having an IPC mechanism in place that makes sure not to introduce "hard-coded" assumption about the underlying aircraft/systems etc.
Given that Stuart said that he is considering to extend svg.nas as needed (e.g. referring to the patch adding raster image support or external SVG files), that also means that non-coders (e.g. Inkscape/GIMP experts) can get involved much more easily without having to know anything about Nasal, Canvas or other coding stuff.
Concerning your comment on CDUs, my take on this is that the answer is basically pretty much in the same ballpark as the "dual-control" stuff - simplly because we don't currently have any well-developed CDU framework in place that is using a similarly sophisticated architecture as the FG1000 - which also applies to other existing "framework", including the original ND/PFD framework shown on various Boeing/Airbus aircraft.
It is my expectation that, over time, the FG1000 will be established as the "go-to" reference for people wanting to do similar stuff - including comparatively simple "single-page" MFDs like an PFD or ND - sooner or later, we will see more aircraft developers adopt the instruments, and probably reach out to Stuart to add more features - which will probably be the time to review how styling/theming and skinning is currently handled at the MFD layer, because if these concepts are well-encapsulated, other experienced aircraft developer teams could get involved in Stuart's FG1000 effort - e.g. folks like the extra5000/Avidyne Entegra R9 team which have been testing the limits of the Nasal/Canvas approach for 5+ years meanwhile, and whose expertise could become instrumental to turn the FG1000 into a generic framework to help simulate similar devices, including the R9 specifically - which would also benefit them, while also making some of their work available to other aircraft/aircraft developers, without them having to use any copy/paste.
Anyway, that's just my 2c obviously ... Stuart, Richard and others (especially the E500 folks) may obviously have a completely different take on the current situation and ramifications of the Fg1000 effort