The only difference between self-signed and purchased certificates is that the latter has a chain of trust established. This means that the clients can trust your server identity without asking the user, as a trusted party has signed your certificate and therefore it can be assumed that it hasn't been tampered with. The actual encryption algorithm(s) and cryptographic strength is exactly same whether you self-sign your certificate or purchase the signature for it.
SSL/TLS by itself does not do anything that would render it incompatible with URL rewriting. That said, you need to be careful about the protocol prefix and/or the port, if your system uses them somehow. HTTP default port is 80, while HTTPS is 443 (although almost all servers can be configured to listen to different ports regardless of the protocol). For example, if you hard-code some resource paths with the absolute URL, note the small but real difference between http://something/example.jpg and https://something/example.jpg :)
Domain name is used with verifying the certificate owner's identity, along with the signature trust. A SSL client is free to choose to ignore the protection that the domain name association gives (for example, common browsers will let you proceed even if there is no match), but this would also cause the effective security and manageability of the system to decrease.
For development, self-signed certs are ok because developers can of course trust a certificate they themselves created. But the chain of trust is very important when giving access to other people, so purchased signatures are the way to go when you publish.