My observation is that responsibility for the persistence layer may lie entirely outside the scope of projects that use an ORM of any description. Making the ORM responsible for defining the persistence layer in this case is worse than useless; it is dangerous.
Many projects leave database issues entirely in the hands of specialists who have their own tools to design and implement data structures. The current design of RoR handles this situation since it presents migrations/DDL as a standalone and dispensable feature. Used when needed and ignored when not.
I believe this is as it should be. Creating a database structure has nothing at all to do with programming access to it. Likewise, programming access to a persistence layer is simply dependent upon what already exists. Coupling these two separate functions will not be a happy marriage to my mind.
If you wish to be able to query a model to find out exactly what attributes it considers as relevant would it not be best to simply adopt a convention and provide a well known method name to return a string of attributes? Then designers can add that method and populate its return value in their models or not as they see fit. If the convention is followed then I believe you will obtain what you desire without affecting anything else. If the convention is not followed then that pretty much makes the argument that any other approach to provide the same information will not be valued as well.