There are three main issues with blocking "free" E-mail providers:
1: There are sites where they offer limited free E-mail, but their main use is by paying subscribers. Everyone, even the people who pay their bills there are locked out.
2: One would have to do extensive research in making a comphensive list of what is considered free and what isn't.
3: The die hard spammers will just use a compromised zombie machine and a bogus registration to get around domain name blocks.
I know that blocking the major free E-mail providers does reduce the volumes of incoming spam by a great amount. However, there should be some mechanism for people who only have E-mail access from those sites to be able to obtain accounts on your Web service. Perhaps have requests from the large sites that have a lot of spam be shunted to a moderator for approval.
Another trick is to have some type of curve ball that automated web bots won't pick up: You can do a message telling users to fill in zero details (such as name, URL, chat IDs) on the enrollment forms except their username and password, saving that info for a later time. Then when processing a form, sent an acknowledgment that the form went through, and then roundfile it, perhaps blocking subsequent requests from that IP address for a period of time like 3-5 minutes with a 502 error.
One forum program named Beehive had an interesting feature called "worm mode" which fooled spammers. It would allow them to create accounts and post, but only they could see the posts that they made... the rest of the world didn't see it. So, a spammer could have a field day until caught and banned, but they wouldn't be able to affect anyone else on the board.
If the Web board is private and members only, you can have functionality where an existing member creates a registration seed code and communicates it to the new member. This does two things. Without explicit communication, people won't register, and you can track who gave access to a spammer.
Finally, if the Web board is very private, you can always force client certificates. Spammers would not go to the trouble of obtaining a client certificate, and the user would only need one while creating a userID.