Hi,
officially we don't support this but I don't think there should be any issue with it. Only one issue could potentially be during upgrade to next version.
So I would say that change could be fine but before any upgrade you should remove these default constraints from database (in order to be sure everything will be ok).
Good to know, thanks for the information. I think this would make a reasonable feature request, supporting default values for custom properties along with providing a tool or adding on to the custom property editor to give the user the option to set the value.
Yes it could be small but useful feature so I definitelly agree with it. But I am not the one who decides about features 
So please feel free to create feature request.
Hi jron--
You can submit a feature request for NPM here. If you do, I will link back to it here so others can add to the vote.
Thanks!
DH
Thanks DH, I have posted the following in the feature request section
Also I have to say Thwack is pretty sweet, I didn't expect to get any responses at all the same day :)
Thanks for sharing that link! You're making part of my job easier ;)
Thanks again,
DH
If you ever want to remove the custom property in the future, you will need to turn off default values. I had that problem removing one when I had a default value, but it wasn't setting the default value too, although I had that property since 8.x so that could be why there was weird stuff with it.
You should be fine. I've given my custom fields blank default values. The upgrades haven't touched them.
Document your changes to be safe!
jron, if you don't have a huge number of alerts, perhaps you could modify them to require the custom property not equal NULL. I can't recall particulars, but I seem to recall running into this.
If you have a huge number of alerts, I can see where your approach would be the lesser of two evils.
