I'm going to add another answer just to keep the history of what doesn't work in this question.
That being said, I finally got it to work through customBinding. This time I've triple checked that IIS is requiring Client Certificates :)
It involved creating custom bindings on the Receive Location of one BizTalk Application and the Send Port of another, why? Because our project involves one Biztalk App sending to another.
So, to get it all to work I had to:
Receive Location (receiving application)
- Use the WCF Publishing wizard in Visual Studio to republish the the Receiving application using the "WCF-CustomIsolated". I wanted a fresh start and wanted to let BizTalk/Visual Studio do their thing instead of guessing.

- I went and edited the Receive Location in the the BizTalk Admin console.
- Set the textMessageEncoding messageVersion attribute to Soap11 because that's what we've been using
- removed the
httpTransport
binding element, because if you don't do this, you can't add the httpsTransport
element which is require
- added the
security
element. At this point, it looked like so (order of elements matters)

- the
security
element has an attribute called authenticationMode
which was switched to UserNameOverTransport. Despite the name, this is what allowed the UserName to be sent along with the Message. Everything else in security
was left with the defaults

- the
httpsTransport
has an attribute named requireClientCertificate
this was set to "true" everything else was left with the defaults.

- then added the behaviors we required, which was pretty straight forward and after that, the receive location was done.
Send Port (sending application)
This was nearly the same as the Receive, but just on a Send Port instead of a Receive location.
- on the Binding Tab, I repeat the exact steps as outlined for the Receive Location
- Behavior tab I added the Behavior extension called
clientCredentials
and in the ClientCertificate element set up the the following values, which just grab the client cert that is in the Current User Store for the service account that your Send Port runs as.
- Credentials tab I entered the UserName credentials that were previously entered in the Security tab of the WCF-BasicHttp adapter send port.

Once this is all done, the 2 applications should now be able to talk to each other using both client certs and UserName authentication.
See my answer to this question as to what this basically translates to in a non-BizTalk WCF service. How to supply both UserName and Client Certificate in WCF client (why does this example work)?
And don't forget to restart your host instances.
Edit - Bonus if you end up exporting/deploying to a different server, even if you export and import/install the Web Directory separately, you'll probably get an IIS saying it can't find the endpoint for MyService/Myservice.svc thinking the receive port/location are disabled. However, it's because it's now a WCF-CustomIsolated. The solution: open the .svc file for the service that is published and change the Factory
attribute from BasicHttpWebServiceHostFactory
to CustomWebServiceHostFactory