To play devil's advocate, smart phone based solutions exclude a huge portion of Internet-connected users. This includes users on computers without smartphones and users on smartphones without computers.
As a result, this design inherently segments out the login to only the upper tier of affluent users. Depending on your application, this is either a huge win or a huge barrier. All about your context. If this fits your target user based awesome. Eventually, though, a normal email-password solution may be needed if you grow your market out to the more general public.
Still, a promising idea. Just go in with your eyes open to the tradeoffs.
The need for an extra device to take a picture of the screen could be eliminated by simulating it with screen-capturing software.
That'd be less secure than a completely separate device with your authentication data on it, but no less secure than current-generation password managers as far as I can tell.
At that point, exactly which of "something you know", "something you are", or "something you have" are you authenticating against? I am quite sure an attacker can get access to "a computer", somewhere, upon which he can claim to be me, at which point you will serve him a bar code which he will confirm does indeed correspond to the account he is trying to hack.
Even the whole "use a cell phone for auth" is not really a good idea. It at least sort of qualifies as "something you have", but a great deal of the identity that you "have" isn't in the physical hardware, but in the cloud and the connection the device has to the cell network, which as "something you have" goes is pretty low-grade security.
"Something you have"- the computer that you are on. You would only store your authentication information on one machine running the virtualized camera auth system, just as it would be stored on your otherwise-separate smartphone. An attacker would not just have to get access to "a computer"- they'd have to get access to the computer that can authenticate as you. This is little different from requiring an attacker to get access to the smartphone that can authenticate as you.
If you have a key on the system you are on, just use it. Your complicated system of barcodes and virtual scanners adds nothing but complication to what was already a secure system. Or the system wasn't secure, and you can't use the insecure system to validate the security of the insecure system.
You and thedufer aren't doing this right. You see one objection, then bend the system to meet it, then see another objection, then rewrite the system to meet that, then so on, never considering the whole picture. You can't do security that way. You have to do it holistically. The whole system that you come up with has to be simultaneously secure against everything, and also needs to be the best possible solution. If you're looping a design around trying to solve one problem at a time (and not necessarily all that well) you've already lost.
Its "something you have" - your private key. Someone would have actually get access to files on your device (or the physical device itself) to beat the system.
As a result, this design inherently segments out the login to only the upper tier of affluent users. Depending on your application, this is either a huge win or a huge barrier. All about your context. If this fits your target user based awesome. Eventually, though, a normal email-password solution may be needed if you grow your market out to the more general public.
Still, a promising idea. Just go in with your eyes open to the tradeoffs.