I will say it's important to understand how the Salt we return is generated. 

Not in the slightest. It is the HASH of a HASH of a HASH. There is no academic rigor to support this gives you any additional security. And a lot of academic rigor that states it is a moot operation.

      The Salt1 is still private on the site's server, and no passwords can be cracked without it.

1) If you argue any SALT is private... Then WHY EVEN USE SALTS?!?! If something on the database is private/secure why not use clear text passwords? The whole idea of using SALT+HMAC is that NOTHING stored is private/secure. You cannot EVER assume SALT(s) are private.

2) Cracking the password is irrelevant. All that is needed is:

      SALT2 + Web transferred hash

Then the credentials are gained. Yes learning somebody's password, or several million's peoples password is a fun experiment but gaining access to the website is also an attack vector, one your system is making easier.

For a traditional HMAC/Scrypt/Bcrypt recovering the password is a critical part of this as the authentication mechanism is a single black box program. Input is SALT+Password+Hash. Output is an auth token.

The system you describes breaks this dichotomy. No longer must the password be broken to gain access.

:.:.:

       Availability is a legitimate concern

An extreme one

       Similar to SMS multifactor

SMS Multi-factor is depreciated. Faking SMS from an arbitrary phone number is extremely trivial in practice. Look into Dave Kennedy's work on social engineering.

Multi-Factor auth is best done via Tokens or TOTP.

       We direct peer to many of our customers and route over private IP space to avoid a potential DDoS.

So instead you want to just install your own box on the customers network? This opens up even more headaches about managing and authenticating your access to their private LAN. Then you get into patching agreements, possible OS limitations, security audits. This is a horrible solution for both parties.