It is possible, but can be very problematic when you try to support this concept in $expand queries or for $filter or $orderby in nested paths (so for any field not directly on the controller target class.
Here are 3 options:

1. Override EnableQueryAttribute, and implement field replacement logic in OnActionExecuting, this allows you to modify the url before it is parsed and validated by the Controller, so you can inject your field replacements into the requested $select argument. The same concept can be used to manipulate $expand, $filter and $orderby but it looks like it could be a bit of work.

2. Use OpenType definition, manually add the dynamic fields into the result set after you have loaded the default data record lookup from the db.

3. Use Untyped controllers, where you can generate the structure based on your database configuration. You will then need to handle crud operations manually like GET,POST,PATCH,DELETE however as the configuration is in the database, this becomes an automated process where you only have a single controller class that handles all tables that you define this way.

I use a mix of these solutions pretty frequently now, for scenarios where the user can change the name of a field then EnableQueryAttribute works well enough, but I don't try to support nested filtering on these custom fields and I'm not sure you could bring field in from different nested navigation properties without a lot of trouble (this would probably involve using an OpenType definition).

To support the user being able to pull in mapped fields from nested relationship properties and serve them as root fields I use OpenType, this means that the user must explicitly request these properties in the $select argument or the fields will be trimmed by the serialiser in the response.

I use UnTyped controllers for scenarios like yours where the end user can change the schema that they use, in my case I have a table of ListDefinitions and ListFields, separate to storing the records, My UntypedController parses the user request and looks up the ListDefinitions to know where to build the results from.

Closing due to inactivity.
Feel free to reopen