My short answer: not that I've been able to determine w/ OpenSSH.
My long answer:
This is such a great question and rarely thought about in my opinion not to mention a difficult and sometimes touchy subject. Both answers so far are good. Certainly you can "hard code" your password in an Expect script. Additionally, the answer regarding unlocking your private key is valid as well. Nikolaidis gets it closest in my opinion as far as answering the question.
The bottom line is that there is no method to specify or submit on the command line your password in a non-interactive manner during ssh authentication using a built-in mechanism (that I have found).
This may be an RFC thing or it may be an implementation thing - I'm not sure. My guess being it's an implementation restriction since I doubt any RFC would specify "how" a password must be handled in the process - but hey I could be wrong. A private key is on some level just a very, very long password and those are often stored unencrypted and there is no implementation restrictions pertaining to that.
But beware.
Now I realize that there is more to asymmetric cryptography (public/private keys) than just logging in to a remote system and that there is more to what it means to authenticate oneself than this discussion. What I'm referring to is the difference in user perception and use between the two methods of authenticating oneself (more to Daffy's answer).
So here's the deal (my take):
If you are performing 2-factor auth then there's generally a reason behind it: someone really wants to make sure that A: a human being is performing the authentication and B: that the human being really is the human being he/she says they are. There's probably a good reason for it.
This may be due to compliance due to existing law (Sarbanes-Oxley) in which case if someone determines you're bypassing authentication in a way that creates undue exposure or against company policy - like during an audit - you could find yourself in a touchy situation and/or with a pink slip.
My point being make sure you understand what you're doing and document what you're doing as well as document the appropriate sign-off by your higher-ups. But at that point why bypass things and rather just figure out if it's the appropriate auth for the situation.
There are plenty of instances where it's understood and expected that a remote system needs to talk to another remote system on behalf of a "user" - like transferring files, monitoring systems, performing backups, etc. In those situations it's fine to setup 1-factor auth using public/private keys and just as importantly, some of those non-interactive auth mechanisms touch sensitive files (backups).
The key (no pun intended) is to make sure the right authentication mechanism is in place for the right situation. People need to get work done and that needs to be balanced with robust security. Which is why there are authentication mechanisms being invented / have been invented since the days of passwords - Kerberos, Smart Cards, eyeball scanners, what-have-you. There are upsides to each as well as downsides. None are perfect (perfect being a subjective concept).
Hope that helps.