One of the major barriers was explaining that the actual process of moving to secure, unique passwords requires changing them manually at every service in a repeated sequence of back and forth between the service' configuration and 1Password. Users expected the changes made in 1Password to apply and automatically sync to whatever service they were changing at the moment, which is of course not possible.
Another issue were domains, which are basically the only way to connect a 1Password entry to a website. Naturally I had to explain to keep the website/domain attribute as short as possible to avoid problems like 1Password not recognizing that the current website at foo.ebay.com does in fact belong to the entry with the attribute bar.ebay.com. This isn't helped by the fact that 1Password automatically suggest creating entries it recognizes as new, which often include specific login domains and urls. Setting ebay.com as website attribute is the right way to do it, but of course this is rather confusing for most people.
I'd argue that most people might be better off without the browser extension and should instead start with the simplified copy and paste process of manually opening 1Password whenever a sign in is required.
Of course it is possible, it's just not implemented. There have been proposals for standard URLs that would accomplish this, but none of these have taken off.
Just wasn't sure if you meant not possible "today" or not possible "at all".