Abstract Views admin UI into separate module, so other modules can re-use it

The new UI of Views is a great approach on a rather uncommon interface design problem: It allows to configure objects that can contain an arbitrary number of elements, whereas each element can be configured on its own without loosing the context of the overall object. Also, elements can be re-arranged within the same interface.
I know at least two other modules that would greatly benefit from this UI, too - actually, one of them (User Display API) is currently hold-off, because a proper user interface solution is missing.

I have tried to wrap my head around views_ui in the past hours, but was not able to proceed as fast as I thought I would. Earl already placed the tab handling classes and theming functions into an own include file - so moving that was rather simple. However, tabs.inc provides those vertical tabs only (for selecting the display in Views) -- the contents of these tabs are built and generated in custom theme functions. Also, the form for editing an item is currently not tied to those tabs (it has just been styled to look this way). Of course, the AJAX magic is quite specific to Views, too, and is spread all over admin.inc.
No insults here, I just did not expect it that way, given that the rest of Views and Panels are so overly abstracted. ;)

An easy way to understand how Views UI looks under the hood is to temporarily rename views-admin.css. The output looks pretty trivial afterwards.

However, before wasting too much time on an approach that might not work out in the end, I think we should define a scope. I'll give it a shot:

• An admin UI module should cover the complete UI, i.e. including the edit form for configuring object elements and AJAX magic, so that it can be maintained and improved independently.
• Objects (here: view) need to support multiple elements (here: displays).
• Object element categories (here: "View settings", "Basic settings", ...) as well as object element summaries (the category contents) should be structured contents, i.e. arrays/objects.
• Object element categories and object element summary items need to support optional action links/buttons (here: f.e. "Change view style settings").
• AJAX callback handlers should be defined once by the admin UI module, executing the corresponding actions in the implementing module.
• Styling.
• Actual object element configuration forms as well as the live preview of a view should not (yet) be part of the admin UI. However, it should provide hooks to allow dynamic preview updates.

That's all I can think of for now.

Btw: While compiling above list, the object element category panes and action links somehow reminded me of the content administration of Panels. I immediately asked myself whether it would be possible to build and render a panel programmatically, i.e. without touching Panels' configuration... This cross-frontier thought might be completely ill, but maybe also worth to consider.