Yes you can change the name of the RDS instance, but it is highly discouraged to do so in LIVE Production environment. It would change the EndPoint which might impact other resources actively accessing the RDS server (like an application server).
This would probably require a property / env-variable change in your code or configs (which would ideally end up for a release of config through config management)
To avoid disruption (In future) and rollout changes with lesser RTO , you can create an intermediate DNS entry (CNAME) in Route53 for your RDS server and use the intermediate URL in your application. When the RDS server name changes you could just change the DNS CNAME of the new RDS Endpoint. NOTE: During the name change your RDS server would be unavailable (with old name) for few minutes and this might cause disruption
That being said, you are already biased on a solution (change of RDS names) for your problem. BuT
There are multiple solutions for your actual problem (managing RDS servers for each project)
A. Try to avoid using AWS Console as much as possible. Why dont you start looking into AWS CLI (which can pull the tags) and write a wrapper Python/Bash script to list all the RDS servers - with Project Names, from this output you could manage these servers, like take a snapshot , backup etc. You can also use mysql --login-path (If you are on mysql for DB administration)
B. (Cost agnostic approach) If you have anyways decided to change the RDS Names, then there is something you can do without any impact.
B.1 When the next code/config release happens try to bring in the intermediate DNS change into action.
B.2 (Optional) Enable Multi AZ in RDS (HA and twice the price). This will help your application to access the secondary active slave when there is any disruption due to name change. There is an option called Reboot with failover which would reboot the master while failing over to the active secondary
B.3 Enable replication (read-replica) (this will give you a new RDS end-point). Name the read replica properly with your project names
B.4. Once replication is complete (and during your SLA / maintenance window) promote your read replica (this will break replication) and make the intermediate DNS point to the new RDS (with your proper names)
NOTE All the above approaches would not guarantee data integrity and improper data updates due to in-flight transactions. So it is
always better to stop all transactions (by stopping all application
accessing and deploying a maintenance page and do the operations)