The custom domain you select will be used as means to represent/access your Auth0 service HTTP endpoints. This means that in general, you will want to select a subdomain of your own domain as login/access management will be just a part of your online presence so you will usually want to reserve the parent domain for a landing page or marketing site. Due to the above, a usual selection for custom domain will be login.[yourdomain].
In terms of your specific points; the custom domain will be directly associated with only the endpoints for login so you will need to use a (sub)domain different than the one you want for the application. Following your example, the custom domain would be login.oursite.com and the application would be accessible at app.oursite.com.
Technically the custom domain could even be located in a totally different parent domain login.example.com, however, if the application and custom domain share a TLD+1 (in this case, share oursite.com you have less to worry about in terms of possible implications around the browser concept of third-party cookies).
If you use a custom domain certain social providers like Google will indeed surface the parent domain of the redirect URI which will mean the user will be less confused.
In order to configure/verify a custom domain you will need to own a certain domain so that you can manage the corresponding DNS, however, application development won’t be impacted and you can still develop (applications) using localhost as long as configuration in Auth0 allow to use localhost in callback URL’s.