The first step is to distance the domain of your project from the domain you use for user-generated content.
Examples: github.com vs. github.io, wordpress.org vs. wordpress.com (note that these are not subdomains, but distinct domains).
Doing so allows you to keep the two separate as far as SEO is concerned, so that your main project isn't affected regardless of what users might upload.
Then it's about putting out the fires whenever they appear.
I'd also be careful about JavaScript, since a site hosted on example.com/a will have the same origin as a site hosted on example.com/b (and therefore access to cookies). This is where a separate subdomain for each user comes in handy (so a.example.com vs b.example.com), which shouldn't be much of an issue since DNS providers usually have an API that you can call, and DNS updates should be fast when you're creating entries (as opposed to modifying existing ones).
Re/ JavaScript — as of yesterday, we serve everything in an iframe with a different origin. This should make us more robust against screw-ups, and will be essential when we start allowing script blocks in pages.
Re/ SEO — we might banish all pages without subdomains to smth like `page.brick.do/...` as opposed to `brick.do/...`. Hopefully that will help with SEO somewhat.
Spam and abuse aren't exactly minor problems for publishing platforms, they're arguably the primary existential threat, the most important thing to address. Preventing them is capital-H Hard, and not the kind of thing that can be easily retrofitted to an architecture that hasn't been designed with them in mind from the beginning...
1) Mine, Heroku, we host your applications on the herokuapp.com zone not heroku.com. Putting customer sites on heroku.com would open that zone up for the kind of de-valuing the OP suggested.
2) Look at Github, githubusercontent.com is where your uploaded files are served from, not github.com. For the same reasons.
