The only issue I see with this is name collisions if you will pull in values from other libraries. For example, the accelerometer library will pull in sensitivity values from an unrelated light-detector library (or another accelerometer library that uses different ranges). More explicit types (like accel-sensitivity) would help, but not eliminate the problem. Worst-case scenario: an input pin that accepts any value of data-type suddenly becomes an enum because another library used the same data-type name for an enum (not looking for enums in other libraries if none exist in current library would eliminate this issue – and save search time). You might also require flag to indicate that a node is to be used as an enum value (so random nodes don’t get pulled in); enum-2g name instead of just 2g would be one option (“enum-” could be stripped when displayed in drop-down for selection).
One way to eliminate namespace collision would be to provide a method of specifying which library the enum node should apply to. Node names are one option like 4g@nkrkv/accel or 4g(nkrkv/accel); no library implies it is only for the current library (or allow “.” to indicate current library). “@” in node name could be the indicator that it is an enum node. A way to specify multiple libraries where it can be used would be a bonus, but probably much harder to implement.