Could scrypt salts contribute to entropy if passwords & salts are only stored in human memory? I'm unsure of how exactly the salt is manipulated by scrypt and its potential contribution if any to overall password entropy if passwords &amp; salts are stored only in human memory for a decentralized implementation.

For this implementation, a cryptocurrency login where the salt does not exist in any repository such as a user table because the resulting hash is the accountholder's signing key, a user would be responsible for generating a "username" as the salt and a password.  Both would be checked for minimum combined entropy such as naive entropy / 2 &gt; 80 to push the user toward Diceware.  There are currently no other requirements.

The username approach was selected because of statistical evidence showing that their distributions possess more than 35 bits of entropy, but I do realize that this set is probably skewed because of users wanting taken names and settling for besthashcracker11 which of course will be impossible to enforce thereby reducing that number.

If that scheme is more vulnerable to the average user than the risk of a weak password/passphrase alone, should a single passphrase be broken arbitrarily into two parts?  If so, how?  What percentage should be the password, and what for the salt?

If salts do contribute to entropy for this implementation, how can total entropy be calculated as a function of password entropy and salt entropy if an attacker has no access to the passwords, salts, or resultant hashes?

Users can be expected to be almost totally anonymous to an attacker.
If you use a potentially guessable username as the salt, you should add a global salt that no other services or programs will be likely to use for scrypt. For example, a long random number. That ensures that attacking another user database does not simultaneously allow attacking your users' hashes.

However, if two users are allowed to choose the same username within your userbase, adding global salt is not enough. You need something unique per user to use as salt instead of or in addition to the username. If random numbers really are not possible, consider using email addresses, which should be unique. (Those naturally add no entropy.)