Burke is right that what you’re proposing here is hacky and not the ideal solution. That said, I believe what you’ve done could work in your use case, and that your use case is the most common one. (So I’m not actually suggesting that you have to change anything at this point. When I tried to actually code this the right way it was surprisingly difficult and I gave up.)
The practical problem with your proposal is that your angular model will then include some things that came from the server via REST (and therefore are correctly moved from the server’s timezone to the client’s timezone when becoming javascript Date objects) and things the user entered via the UI (which are incorrectly in the client’s timezone, and you want to strip the timezone from). So you’d need to make sure you only ever apply your serverDateForRESTSubmit filter to a user-entered date and not one you got from REST.
Wyclif is also correct that this would ideally be an admin-configurable setting (e.g. whether the client UI should be in the server’s timezone, or in the client machine’s timezone).
Ideally we would have a date+time picker widget that (depending on configuration that can be in a GP or hardcoded by the dev) may presume you’re picking a date+time in the server’s timezone and hence convert this to the correct client timezone before putting the javascript Date object in the ng-model. (I would try to use moment-timezone for this.)
Someday someone needs to write a date+time picker widget for the Reference Application. I posted about this here, but never created a ticket (and I guess this should be updated to mention timezones):