The value list will work just fine, but you may have issues getting that name field to update as changes in the related table that it references won't trigger automatic updates of this auto-entered calculation value.
I struggled with getting a value list to work using a primary key and showing the second field only of a calculated "full name" field, because the calculation was unstored (to update if the first or last name was changed/corrected). I saw a number of complicated work-arounds, but stumbled upon a seemingly simple solution.
I use that sort of setup and it works fine but, as you've discovered, won't produce the list if the calc is not indexed. A couple of points:
1. You say you have left the full name field unindexed to make sure it updates if data is changed. This is not necessary. The calc field will update, even if indexed, if one of its feeder fields is altered. Switching off indexing only forces it to recalculate every time the field is displayed, which is unnecessary, and also prevents its use in a value list. Switch on indexing and you'll be fine.
2. You "solution" is a needless recipe for potential trouble in my view, as it effectively duplicates the data which means it needs to be updated if feeder data is altered—not impossible obviously, but much simpler the other way.
3. The above is based on my assumption that the full name field exists in the same table as its feeder fields. If this is not the case, then you will not be able to index it.