...
During the pilot, a service's particular error or alternate login page will have an additional button called "Try authenticating via Touchstone". So for example, if you try to log in to Stellar and your certificate does not work or you do not have one, you currently get the page below. 
When the Touchstone pilot goes live, there will be an additional section underneath the current MIT Community Users section on the page below.
During the initial phase of the pilot the pilot applications will always require an explicit customer action to "try Touchstone" if login fails by default. It should never re-direct there automatically, unless the user has at least once chosen to use Touchstone and set explicit preferences for their use of Touchstone.
Here is a screen shot of what a user of Stellar will see if a certificate is not presented to Stellar when logging in:
The login page for http://wiki.mit.edu is intending to take a similar, yet slightly different approach as seen here: 
2) There are some "start-up" or transition aspects to using this service. It may slow people down, or require them to get some additional information before they can get to web-based information on which they depend to do their work or studies, and which is time-senstive. What can we say to someone about the benefits of this new system, which helps to offset the unfamiliar way of going about old tasks? We would expect clients to ask the following questions. What answers might we give?
...
MIT Touchstone is in its early phase of deployment. You are likely to need certificates to authenticate to other web applications at MIT for the foreseeable future.
MIT tickets issued to users typically expire near the end of the fiscal year when the certificate was issued. MIT users may select to have a certificate with a shorter lifetime. The certificate that expires in 2026 is the MIT CA (certificate authority) certificate, that certificate is used to validate the user certificates. The long lifetime is used so that users should not have to reinstall the certificate during the useful lifetime of the computer.
User should also remember that when properly used, certifcates provide a better defence from having your account compromised by phishing attacks or other mechanims than simply using passwords. MIT Touchstone supports username and password authentication only because certificates and other strong authentication technologies cannot be used on all systems everwhere in the world today.
...
Similarly, why/how to choose between the "Authentication Options" (https://idp.mit.edu/auth-options) radio buttons? What about putting a link called "How to choose between these options" to documentation or some background information at the top of this same page?
4)
...
It may be difficult for clients to know whether they are having difficulties with Touchstone, or a different product/service to which it provides access. If the Help Desk identified the problem as a Touchstone issue, what items of information is it useful for us to collect in order to escalate?
- What is the name of the customer?
- What was the time and date when the problem occurred?
- What URL was the user trying to access?
- What browser was being used? (Brand and version)
- What application was the user trying to access?
- What machine was being used when trying to access the URL? (Physical location, hostname, IP address if known)
- Which authentication method(s) did the user attempt to use? (username / password, certificate, existing tickets)
- What error message was displayed?
...
The current default MIT Touchstone login page: 
The following page is normally briefly displayed to a user as the system redirects the user's browser back to the originally requested URL when the user has successfully authenticated to the MIT Touchstone login server, and has JavaScript enabled. If the user is on a slow network link this page may display for longer than the user expects.
Alternatively, when the user has disabled JavaScript, the following page is displayed after a successful authentication; the user will need to click on the Continue button to proceed back to the original site:
The user has five minutes to authenticate successfully from the login page (a timer on the page serves as a reminder of the time remaining). If the user attempts to authenticate after this time limit has been exceeded, the following error page is displayed: 
Touchstone requires that the user accepts cookies from the participating web sites, including the login server, idp.mit.edu. If the user disallows cookies, the following error will be displayed when authentication is attempted (unless the application web server detects the problem before authentication): 
Once the user is redirected back to the original web server, the Shibboleth software on that server normally creates an internal session for the user (so that further interaction with the login server for the user is unnecessary). If this session creation fails for any reason, for example if the Shibboleth daemon is not running on the web server, the user will see an error page similar to the following; note that each web application server will likely have a customized version of this page, to match the rest of the site, but, if it has not been customized, the following stock page is displayed:
It is possible for the user to encounter the following error page. This should be very rare. I obtained this screen shot by using the Firefox extension "Tamper Data" and modifying the contents of the data being sent back to the login server when logging in using my username and password. 