Howdy! Thanks for all the detail on the issue you’re experiencing. Hopefully we can help you make some sense of the issue and ultimately resolve the root cause 
There are certainly a lot of variables here but if you could start by sharing a screenshot of your Modem Info screen (the logged out version with your sensitive information redacted) and confirming what specific plan your SIM card is provisioned with (T-Mobile Home Internet, T-Mobile Business Internet, Magenta Business Tablet, etc.) this will help us greatly. Since you are using UBNT I would also recommend ensuring you have the latest UniFi updates installed as recently the Network Application in particular has had some known bugs with dual-WAN configurations.
Based on your description it seems like you are using a tablet data plan but may not have the InvisaGig configured for such a plan. The smoking gun that most always points to this is the 0.6Mbps download speed you are seeing when running a speedtest. This is frequently the behavior observed when an incorrect Carrier Profile is selected. Under the latest IG software (v1.0.12) if you are using a T-Mobile tablet plan, you would select a Carrier Profile of ‘T-Mobile - Generic Hotspot’ if you are using such a tablet plan.
Another cause for this behavior can be that the maximum number of entries is being reached under your router’s connection tracking and/or firewall tables. Under PFSense we recommend to increase the latter but I’m not sure if the UniFi platform has a documented way of accomplishing this under their standard user interface. However, given the very specific 0.6Mbps download speed you are seeing I have a stronger suspicion that an incorrect Carrier Profile is more likely than than this possibility.
The curl success of ‘http://google.com’ is likely due to the tiny size of the page (it only contains a very small amount of HTML required for the 301 redirect to ‘http://www.google.com’ and subsequent redirects to the local, native HTTPS CDN host for your region). This small amount of data would also be why curling http://icanhazip.com succeeds as well. The curl failure of ‘https://google.com’ is likely due to the TLS certificate(s) included in the TCP headers as part of the handshake process which uses more data.