"Game" Engine Requirements System
I have never written code against a RavenDB, and very seldom use Json (actually, "never" is almost accurate). The way I see it, the classes that end up Json-serialized and persisted to the database, are analoguous to Entities (Entity Framework), or POCO's.

They are part of your data model.

It might seem (/be) code duplication, but if you had a domain model (which might mirror your data model... or not) and a way to "translate" a domain entity to a data entity (and vice-versa), you could very well use an enum in your domain model, and have it serialized as a string.

Basically: the shape of the data shouldn't drive, nor define, the shape of the objects your application is going to work with.

Your business logic (well, the actual game!) should work with the domain model objects, and then you'll have a data access layer that will do its job with RavenDB and Json - the business logic shouldn't be bothered with these concerns.

The Label is a good example of why presentation concerns and data concerns need to be separated: serializing and storing it is a waste, you already have all the necessary information in the other fields.

If you had a domain model Condition, it could have a Label property, with logic to build the string out of the other values.