We don't plan on supporting custom domains, because we don't think people will serve up content directly from these scripts. (We think of them more as APIs, so typically invisible to end-users.)
That said, my startup's other product (www.site44.com) is great for serving up content and does support custom domains. We plan to add support to Site44 for forwarding API calls to Webscript. So you could build a full HTML app with content served from Site44 and API calls handled by Webscript, all with a custom domain.
It is actually not about serving content. Custom domain makes the fail over much easier. For example, someone uses webscript.io as his app backend. If webscript.io goes down for whatever reason, he can simply point the URI to a backup server(provide he has one) if he uses a custom domain. Without custom domain all he can do is wait.
