As far as the parser go this is fine (except that since null is a keyword, I'd rather call the token K_NULL for consistency sake).
But otherwise I don't think treating null as the empty string is a good idea. As you say it doesn't work for strings, but even for other types, inserting an empty byte buffer is not the intent (and in fact this would probably break some type of querying since the empty byte buffer is kind of reserved and special cased in query slices). The intent, as far as inserts/updates are concerned is that setting the column to null is equivalent to not setting it at all, it's just a convenience. Which means that we probably need special handling in the Operation classes (we'll need that special treatment for handling null in prepared statement anyway (
CASSANDRA-5081, which is probably the most useful part of supporting nulls)).
For selects however, null is actually a constraint on the query. For that, we may want/need to update the 2ndary index code to handle that. But maybe that part could be done separatly in fact.
I do want to note that the example in the description of this ticket is kind of bad. In theory, a PRIMARY KEY cannot contain a null value by definition and currently we don't allow them in general. The example in the description is one exception (compact + composite) where we could indeed allow some nulls in the PK, but since it is a special case, maybe we can leave that to a follow up ticket.