The "domain" that I've used is simply a name that parses information from the binding back to HABmin. It's simply an interface definition that provides some link between a user interface (not necessarily HABmin!) and the binding. There needs to be some sort of descriptor, and that's all that this is doing.
Likewise, this is nothing to do with z-wave. At the z-wave level clearly this uses the configuration / association command classes.

The idea of this interface is to provide an abstract definition that can be used to link between the binding, and a user interface. I don't think that the user interface is the correct place to put all the Z-Wave stuff - the binding knows about z-wave, and that's where the translation should be made. Otherwise, the UI needs to know all about any binding it's trying to administer, or a separate UI needs to be built for each binding. If the binding is able to describe its configuration in a more generalised way, then a single UI can be used to admin any binding.

The ultimate idea that was briefly discussed with Kai was to have an interface that allowed a UI to interface to a binding for configuration purposes. There was a discussion on this on the google issues list - Take a look at Kais comments to this in the issues list (https://code.google.com/p/openhab/issues/detail?id=420). All I'm doing is effectively the same thing as discussed here, but with a custom interface. If I remember correctly, the  interface that Kai mentions only has simply single dimension dictionary of configuration items in its UI descriptions which I feel doesn't provide the required level of control.