From your description, I assume you (A) don't actually need access to the users (B) data at any point of time? Ie. A stores B's data, nothing more.
If so, your whole idea sounds pretty bad.
Something about normal asymmetric encryption first:
- The public key is used to encrypt. The public key, not the private key. The idea is that decrypting is hard. It won't be hard if you need the public key for it.
- There's not something like a public-ish/semi-private key. One of the two key holders always can calculate the other key too (but not vice-versa), namely the private key can be used to calculate the public key.
- There's no (single) asymmetric encryption scheme where decrypting needs both keys. You could use two kay pairs, ie. 4 keys, to make something like that, but not a single public/private pair.
Said that, the next problem is your definition of "storage without access". If A wants to store data without having access, why B should send the plain data to A? Because that's exactly what you're proposing: B sends data to A so that A can encrypt it then. Before encrypting, A has plenty access. Same story later when it is decrypted on A's side again before the data is sent back to B.
Third, A gives B a key, and later B sends the key back to A? How are you sure A won't keep the key to have access all the time? And why keys are sent around at all?
What you could do (and it's much easier): A stores the data, like you said, and nothing more. Don't make up nonsenical encryption strategies involving both sides. If B wants the data to be private, B can encrypt the data alone, with own keys and own methods, before sending it to A. A won't ever get any key.
And if you have that, you should think of integrity+authenticity too.