Dependency management by decoupling table name from table key
For tables and columns you could define views. The underlying objects can have whatever abstruse naming you choose. The views would make that human-friendly in the context it is used. When the design changes, create a new view with different names and you're off and running!

For programmables, such as functions and stored procedures, a wrapper presenting intelligible name could simply forward parameters to the underlying objects.

However, I do not think this is a great pattern. A relational table is more than a bucket of strongly typed variables. Columns also encode meaning. Once a column has been christened, say, iso_country_code, no other values should be permitted in that column just because they're two characters long. To repurpose columns makes a mockery of DRI. This is not how an RDBMS was designed to work.

Now, there are many fine dynamic schema persistence layers in existence. These were designed specifically to store items with variable semantics side-by-side. If this is your use-case, use one of these.