Has having configurable table and column names in your queries ever helped you during refactoring,
or am I being paranoid about futureproofing?
I don't think the concern for future proofing is inappropriate, only the proposed solution.
The problem here is that the database is usually the bottom layer of an application.
The structuring and naming of the storage scheme is one of the fundamental items of programming work and the one of the main sources of essential complexity.
If the database schema is overhauled in any way, you'd expect to have to rewrite and recompile any application code, because the application code is closely fitted to, and depends upon, the database schema (i.e. the schema of storage for the data upon which the application operates).
If the database structure is changed, then typically the application logic (not just naming) will have to change to realign with the new structure. Or a thunk will have to be introduced which converts the new structure of the database back to the old structure around which the application was originally written. Such structural change to the database necessarily implies fundamental changes to the application code.
The only time when configurable table and column names would help is when the structure is not changed in the database, but only the naming scheme there.
It's not unusual to want to change the names of things without changing the structure - to incorporate new concepts as the system grows (which requires old concepts to be renamed to properly distinguish them from newer additions), and to ensure that names continue to correspond with how staff think and talk about the system.
This is because the naming scheme (i.e. the internal ones that users never see directly) only exists for the benefit of the staff who work on developing and maintaining the system - the computer could as easily work with unnamed, arbitrarily-numbered tables and columns.
But effectively, your "configurable" names only help you in the simpler case of when renaming occurs without restructuring. It does not help when renaming occurs during restructuring (or when things are restructured but not renamed).
And there's a price to be paid for this "configurability", which is all the design overhead, the boilerplate code that has to be added to support it, the mangling and parameterisation of the SQL code, and an additional layer which links soft-coded parameters to the context of hard-coded SQL text (which, in turn, will probably require a naming scheme, which means you end up with a shadow naming scheme hard-wired into the code again). All this overhead for configuring names may, itself, have to be changed if there were structural changes.
Rather than avoiding maintenance work later, you are making immediate additional work necessary, plus adding significantly to the maintenance burden later (by making the code generally more complex and less obvious).
A category of wrong solutions
This proposal ultimately falls into a known category of error, which is where developers obsess about avoiding any kind of possible "maintenance" which involves direct modification or recompilation of source code, but the solution takes the form of providing auxiliary "configuration data", which is not data in the sense of "business data", but is really just boiled-down source code.
Typically, only a developer with access to and deep familiarity with the application's source code (i.e. someone who could easily edit and recompile the source code directly), could hope to understand what exactly these configuration codes do, and when or how they would be correctly altered.
The right solution
The appropriate way to manage an interface between application code and a database, is to have a data access layer in the application - a concentration point through which all calls to the database pass, and which contains database-specific code like SQL code which incorporates the names of things as they are in the database.
The idea is that if anything changes in the database, you know where in the application you need to look to start updating names or tracing further dependencies (or assessing what impact a proposed change in the database would have).