It's an unusual situation, and I agree that it should be easier to have the two use different language settings.
I appears that the Login snippet uses the core setting because that string doesn't exist in the Login package lexicon files. You might try adding this to the core/components/login/lexicon default.inc.php files:
$_lang['login_cannot_locate_account'] = 'whatever';
It might use that instead of the core value, but only for front-end logins. If it works, you should submit it as a feature request or a bug report.
You'd have to clear the site cache before it would take effect.
One last thing to try (that would almost certainly work) would be to modify the login class file and add a language spec. in the lexicon->load() call that uses the language property in the $scriptProperties array if it's set. That way you could put &language=`de` in the login snippet tag. Something like this:
[[!Login? &language=`de`]]
$language = isset($scriptProperties['language'])? $scriptProperties['language'] . ':' : '';
$this->modx->lexicon->load($language . 'login:default');
This is how the login class should have been written to begin with, IMO.
In summary, a big part of your problem is caused by two oversights in the code. First, the login_cannot_locate_account language string was left out of the Login lexicon files. Second, the $lexicon->load() call in the login class file has no language option. Those would make for a nice pull request for the Login package if you've got the energy.
