By "tenant", I presume you mean that you're deploying multiple instances of the webapp for different sets of users.
You can share a single WAR file (or directory) between as many instances as your hardware can tolerate. Since the WAR is (or at least SHOULD be!) read-only, that's not a problem, although they won't generally share class instances, since each WAR has its own unique classpath. Or in other words, it will require as much memory as "n" separate applications instead of 1 class + n per-user object applications worth of memory. Some experimental JVMs have addressed that issue, but the standard Sun/Oracle JVM doesn't (last I heard, anyway).
If you're using container-managed (realm) security, the login screen is selected by the contained according to the fixed definition in web.xml. Redirection will probably not work here, since this webpage is managed directly by Tomcat according to minimalistic rigidly-defined rules, but you can do a lot just by "skinning" the page based on deployment options that you set. Since a login screen at heart should only be a form with userID, password and Submit controls, skinning is usually sufficient.
Along with general deployment options, of course, you can configure a separate Realm at the Context level for each tenant, allowing you to select not only the credentials datasource but even what type of Realm that particular instance runs under (JDBC, LDAP, MemoryRealm, usw.).
Customer surveys are for companies who didn't pay proper attention to begin with.
subject: Tomcat 7.0 configuration w/ multi-tenancy support & realm security & different login.html per tenant