Database Design - When to use "attributes" rather than additional columns
There are two schools of thought with this type of design:


The developer / DBA.
The users.


The Developer/DBA will want to create a system that self-maintains.  In other words precisely what you are pursuing above.

The Users will want a very simple system that they can understand without really understanding anything other than their day-to-day job.

You will be successfully fulfilling your role if you create a system that is easy to manage and not too difficult to learn.

My experience tells me normally the user wants a flat-file based system where they can easily see all the fields "they would ever need" on a single form, without having to design anything themselves.  As a developer/DBA I have created both flat-file based designs and highly normalized designs.  The flat-file designs were me deciding I could no longer tolerate trying to convince the user that they really did need to be able to extend their design without getting me to do the work in the future.  Needless to say, around 10 milliseconds after I put their "everything I'll ever need" system into production, they wanted to add some fields.  Me bitter?  Never.

If you can find a user that understands how to manage the normalized design you want to utilize, get them on your side and have them vocalize their concerns about being able to extend the design without having to involve I.T. for every minute field change.  Then build a really slick user interface that allows them to build the fields (attributes) they want.  Then build the back-end the way YOU want.  Don't make it so complex that if you put it down for 6 months you'll have a hard time understanding what you did.