Schematic conventions for different supply rails
Naming of things is an important topic. Software people perhaps discuss them more than most, as they have lots of variables and functions to name. Fortunately, you have only a handful.
Names have to meet a number of requirements.
Be meaningful - you shouldn't have to look it up in a cross reference to understand it.
Not cause confusion - not only be unique in scope but also not share too many leading characters with other names
Be easy to use - a 50 character descriptive name takes a long time to read, and is easily mis-typed
Not look weird? I don't think so. Who are you doing this schematic for? It's not to look pretty, it's to be correct. If you have an unusual requirement of several rails, all of about 3v, that you must not get mixed up, then weird looking names might be an asset rather than a liability.
There are conventions, like VCC and 3v3, which are not applicable to your situation. So you need to identify the function of these two rails, in a way that's meaningful to you, won't confuse you, and will tolerate small changes to the voltage later. Are they '3v_and_a_bit' and 'nearly_3v', or '3v_logic' and '3v_memory', or '3v_DSP' and '3v_analogue'. I'd often have rails like '3v3_raw', 3v3_filt1' and '3v3_filt2' when using supply filters to stop parts interfering with each other via the rails.
Refactoring
Although names are important, as Neil_UK writes in his answer, your main issue seems to be this:
the voltage per se is irrelevant and may change as the design develops
Neil_UK makes a reference to software development, and I will make another one: The solution to changing parameters is to refactor. If your rail changes from 3.3 volt to 3.0 volt, just change the name of the net. Since your new rail obviously changed due to a new or replaced component, you already had to make a lot of changes. A global search-and-replace on a net name is minor in comparison.
If you're nice to your future self you will mark this change in a changelog, preferably on the schematic, just as you would if you change the value of a component between revisions. This makes a change even less confusing.