We have a customer who wants their users to use different user accounts for SharePoint Online and Exchange/Office 365 mail (as weird as it sounds there is a legitimate reason for this). All the accounts are in the same domain and the customer has configured ADFS with their tenant. All the articles and posts I can find online deal with the exact opposite of this scenario (either SSO or multi-domain with one tenant).
What I am wondering is if we can configure SharePoint Online and Exchange with different realm ID's (or something similar) so that ADFS can be triggered to use a different authentication mechanism for one realm vs. the other.
Per comments below here is a little more color to the reason for needing two realm ID's (or any other mechanism to solve the issue). The customer has essentially two kinds of user accounts in their organization. Most are standard run-of-the-mill user accounts who access O365 via SSO provided by ADFS.
The other types of users do not normally log into workstations and do not have assigned desks of their own. These users use shared workstations that are constantly logged in under generic, communal accounts. When these users access the shared workstations (I referred to them as kiosks in the comments below but that is a slight misrepresentation) and then try to access O365, ADFS is logging the users in as the generic account. This is fine when the users go to SharePoint Online for the main portal page (when going to secured sub sites the users get a access denied page but there is an option to log in as another user) but not for when they try to access email (they get a error page because the generic account does not have a inbox and there is no means to re-authenticate).
My initial thinking was if we could use two IdP's (or one ADFS server with two RP's) then we could use SSO/WIA for the SharePoint realm, and then use forms auth for the Exchange realm. Another thought I had was using a claim rule in ADFS (they are on ADFS 3/2012R2) to force forms auth if the user's UPN matched a pattern. A final punt solution I had was to use GPO to disable SSO in IE for the communal accounts.