I would stay away from that kind of magic, mainly because it’s going to end up being confusing for users. For a user, it’s better to clarify what credentials you are supposed to use. Also for things like creating a user, verifying that the user exists already, the same user with identities in both places and different passwords, things could get really messy.
I would put a better-worded version of “Do you have an identity in application B? Click here to log in!” in your hosted login page, and let the user make that decision.
Also, consider what will happen when the user chooses to log in with their credentials from app B. Are you going to ask the user for credentials directly in your Auth0 domain? Even if it is a custom domain, it will look like “login.appA.com”. So any conscious user would be very wary of typing the credentials for App B in App A’s domain.
A better solution would be for App B to offer their own authentication service (they can use Auth0 or other idp that supports standard federation protocols), and you connect to App B’s federated identity provider via any of the standard enterprise connections in your Auth0 tenant (like OIDC or SAML). This way, when the user clicks on “I want to log in with App B’s identity”, there will be a redirection to App B’s identity provider to do the login.
Hopefully the above was not overly confusing, but it would be the proper alternative if App A and App B are not directly related, to avoid freaking users out.