By DDD definition, Value Objects are determined by the values of their attributes, and not by their ID. In my applications most often I have some sort of Drop-downs that are filled with Value Objects and selected by the users. Those drop-downs most often are connected using their surrogate keys that where auto-generated by the database engine on the Query side(or GET when it comes to Web Requests). On the other side, when the user wants to persist some data(during POST), only the auto-generated Id is given by the user. Now since the value of the attributes is missing and we only have the Id, it is hard to initialize Value Object without first retrieving it's values from the database and only then persisting it using the aggregate root repository. In this case the Id is more of a metadata, than a Unique Identifier, similar to CreatedDatetime or CreatedByUser fields, and , to me personally, it makes no sense for these kind of fields to be in the domain, as they are more of a technical concern. Is this the generally accepted way of dealing with these sort of things? How do you even implement a repository for value objects and even bigger question how do you decouple it from technical concerns like database generated IDs?
Disclaimer: I think questions about DDD rarely have answers, but are encouragements for dicussions. So this is my opinion with all possible flaws and biases. This is not an answer. But if you really like my opinion, you can select it as the accepted answer... which would be the pragmatism you need to solve your problem :-)
I'll give you an example from my project: sports competition management. There is this concept of an age group, for example "female under 18". You could say that this is a Value Object because it is defined by its values (gender, maxAge, minAge) and has no life cycle. But I introduced an Id because I need to reference it in foreign keys and I didn't want to have 2 columns (gender and maxAge) in my database for referencing it. And a few years into the project, it was decided that the minimum age would be changed. Until then you had to be at least 16 to participate in this age group, but they lowered it to 15. So we changed that in the age_group table / AgeGroup ValueObject.
... so this was the second indicator (after having an Id) that it might not be a Value Object. And it turns out there is a 3rd one: more than one entity referencing the same instance. When we changed the minimum age, this meant that we also changed the minimum age for some competitions in previous seasons... not good!
There is lots of dicussions if a postal address is a Value Object or an Entity. There is good arguments for both opinions. But if 2 people live in the same house and person.address points to the same instance of Address for both persons, then it is an entity for sure.
An example for ValueObject with Id: a person can have more than one way to contact them. so there is person.contactInfos an array of ContactInfo which has a type ("email", "phone", etc.) and URL. For simplicity's sake, I gave them an Id just to make the ORM easier. But when I update a persons Contact Infos, or change the order, I just delete the old ones and create the new ones. Because that's what Value Objects are: disposable and exchangeable. For every Value Object instance in your application. You should be able to delete it and then create one with the same values, attach it to an entity and things are just the way as before.
To sum it up:
For your problem, I suggest following decision path:
If the model object is actually only a string, then it's a Value Object. Maybe just an Enum?
If the same model object is referenced by more than one entity, then it's an entity. You might want to introduce the concept of "immutable entity with a Uniqueness Constraint" like my example of the AgeGroup that has a uniqueness constraint over gender + maxAge
If your model object has an Id just to simplify ORM but is only attached to one entity and you can delete that instance and recreate it without any side effects, then it's a Value Obect with an Id.