Seriously, you should consider having a primary key with two columns, of type date and int. It would take exactly the same space as your current plan, and performance should be very close to what you propose. As long as you aren't using some ORM that is too dumb to deal with this, it should be far easier than creating the custom type.
+1
Most ORMs cannot handle ENUMs, let alone user defined composite types.
That, or they flood the database with SELECT * FROM pg_type WHERE ... queries. I'm looking at you, Cake.
You're far better off trying a (date,integer) key as Kevin said.
If the ORM doesn't allow that, I'd suggest a custom function that encodes the date bit-shifted to the high 4 bytes, and then adds in the four bytes from a cycling sequence. At least then you've got a shot at partitioning, though the lower/upper bounds of the partitions would not make sense to the casual observer.
