Nick, your transaction type is a dimension, as you have already modeled. So a fact is a transaction of a certain type. It is the transaction, not the type, that has the attributes you mention. Therefore, I'd add some fields to the fact table. Those would be: Expiration Date, Active Flag, Process Date, Vehicle ID, and Plate ID. Granted, the last two only apply to a Registration transaction type, but there's no law that says you can't leave them NULL.

In a relational sense this makes for some very easy queries to answer the questions you mention. In a cube sense it's not impossible but will take some playing around.

Does the vehicle_uid equate to a VIN? If so, you could store the VIN as an attribute of the fact record (a degenerate dimension) and then create the make and model dimensions like you show. I don't normally like the centipede approach because a Vehicle is a perfect example of a dimension, but you have an interesting situation. A vehicle dimension is likely pretty flat, and you sure don't want people dropping down a list of 20 million vehicles looking for a particular one. Give them a good ad hoc tool like ProClarity or Excel 2007 and I can almost guarantee someone will drag the vehicle_uid attribute to the rows if you don't hide it.

Anyway, back to the dimension. >20 million records in the dimension is large and make analysis on it problematic. However, it's also a generally cleaner approach than storing a make, model, color, etc. uid in the fact table, thus complicating the model by increasing the number of dimensions. From a performance standpoint I'd be concerned about the large dimension but it really depends on the usage. Is there any kind of logical hierarchy in the vehicle dimension? Could you go from Make to Model to Vehicle and enforce that hierarchy by hidding the attribute hierarchies?