So, just to report back, there was a discussion about it, and bottom line is that since Ruby doesn't recognize 0000-00-00 as a valid date value, and since Rails auto-casts incoming field data, then bringing 0000-00-00 _in_ from the database is going to result in a nil. Since there's no way to _read_ 0000-00-00, there's little value (from the Rails Core point of view) in providing the ability to _write_ 0000-00-00.
Personally, I think there is value to it (when multiple systems share the data, when it is exported for other uses, etc.). To me, the database capability should dictate what Rails adaptors can do, but in the end I didn't bother pushing it further. It would take some code to cope with casting incoming dates of 0000-00-00 values as String, and then the app would have to test for three possible states (Date, String, Nil) instead of just two (Date, Nil). And actually I think Rails provides a way to play with fields before they're is cast? If so, then it could be implemented in the app layer.
The Rails guys of course are focused on a Rails-centric, Rails-only world, so to them the above solution has no value to core.
If an app really has to have the capability, you can also store dates as varchars -- which is what I've done in the past in order to preserve some multi-system data-interchange compatibility.
If we could find where Rails does this coercion step for dates, that could possibly be overridden, but short of doing that the bottom line is to allow NULL for date fields.