It's certainly possible to do what you ask and there are several different approaches but I would suggest that you look deeper at your requirements.
In languages other than Ruby I've helped others architect & build similar meta-modeling CMS frameworks. The first one was done in 1999: full Web GUI for creating models and relationships between them straight from the browser. The reason why we had to do this back then was that the underlying platforms we were using made it rather difficult to create models and do MVC so we had to help developers with both framework code & GUI tools.
Ruby as a language is well-suited for internal domain specific languages. Rails uses internal DSLs a lot, especially in ActiveModel. Because of this, it is often far easier to write the basic code for a Rails model then it is to use some other (higher) level of abstraction. GUI tools, in particular, are very tough to deal with when it comes to building good models because of roundtripping: the need to be able to allow for code to be changed by hand and that change to be reflected in the GUI. It's a tough problem.
With all that said, if you still want to go with a GUI-based meta-modeling approach, there are two main paths you can choose from:
- Building parameterized RoR meta-models
- Generating specific RoR models
From the phrasing of your question it seems you are interested in (2). In that case, there are two standard approaches for going about this: you either interpret or compile. If you interpret then you create a DSL for describing models and its execution instantiates the models in the Rails environment. (In Ruby classes are defined by executing code that defines them so this is all perfectly normal.) If you compile than you'll code-generate standard RoR models that use your favorite persistence framework. The question then becomes where will you keep the code. You can write it to disk and load it. You can also store it in a database, for example. In both cases you may want to look at gems such as sourcify.
On a side note, if you choose to build this type of system, I'd highly recommend you go with a NoSql document-oriented persistence mechanism, e.g., MongoDB using something like Mongoid. The reason is that Rails provides limited support for SQL schema management and even less workflow automation (beyond basic migrations). Give people a GUI and they are likely to mess with schema more frequently. Therefore, you'll have to deal with the schema migration problem. Document databases make this a little simpler (partly by punting on the problem at leaving it to code to deal with issues in a lazy manner). Relational databases usually don't let you do that. They require up-front schema migration effort and that will add lots of requirements to your system and friction to the overall developer workflow.
Good luck!
