I will assume that you are able to create your own wallet, as you said. Under such circumstance, I would suggest that you follow the logic below.
First of all, let's suppose that someone has coded (as blockchain website released some tools into their API section) a software able to create bitcoin addresses for external users. In such a scenario, if the algorithms contained in such software, hosted in a server, can create a multi-signature wallet for the users, in the meaning that certain user would need both private keys (2 keys per each address) created by the software in order to spend the coins from such a single-address wallet, and if for example the server keeps the private key A and deliver to the user the private key B, then we would have the situation of a "hybrid online wallet" where only the user can use both keys, A + B, in order to create, sign and broadcast transactions related to his bitcoin address. I speak here about the case where only the user is allowed to proceed in order to spend coins.
Such a system would be pretty secure for the user if the software owner would have no knowledge or interaction with private key A (or B) and if the encryption used before storing that private key A would make useless to any third party (even if reaching there) any access to that stored key from the server's database.
Now, on the other hand, the sole way to construct a transaction and to sign it with both private keys might take place only in the server (this being a very important condition, as I will explain later in this scenario).
If the software owner is willing to let the users to leave the server with both keys (for example, just to delete their accounts and establish such addresses as some truly cold wallets), he might employ two options.
One would be to release directly to the user the private key A, thus empowering him to use elsewhere (if and when needed) the keys A and B for signing transactions, or the other (somehow better one) in which the algorithm allow to create a third key, the C key, which could be used in conjunction with key B in order to spend coins from that address. In other words, the user leaves again with two private keys in his pocket, enough for him to use them for depleting the corresponding address (public key). That can be realized either by using a seed (certain "D" private key), unique to the server (or to the user account), or establishing as seed even the key A. If the key A is used as a seed, then practically anyone with access to the source code of software could replicate the entire range of addresses created for the specific user (if the key A is "user-account-specific" and not "address-specific"). I see the last one as impossible to be used by any decent sysadmin (if he has the smallest idea about the risks incurred in such a low level security choice). So let's assume the server creates seeds with higher privileges (aka user-specific). That, again, could have catastrophic consequences for any careless user that would import that key A into any wallet from a device infected with malware. (Maybe that reminds us somehow of the Electrum wallet ? :/ ...)
The last option available which stands is that where the server has an own seed key (with highest privileges) which cannot be accessed by any third party, and that combined with at least another one (server protected with multi-signature, too).
Back to your situation, you should have the key B offering elevated privileges (enabling you to create keys D, and further, but anyone using the D to not be able to create other keys). Because, though, such thing would be a burden to code, I would suggest some simpler option : the one way - one size shot - transaction. Which means that you import in any wallet of your choice the keys after some sweet cleaning of the basic functions. As once said Henry Ford about his cars "you can order any color, as time as it is just black".
The imported address, wherever be it stored, might be coded such as to make possible one single operation: send a payment of precise amount solely toward another address X of you (for example, only can send each time about 0.1 BTC toward your hot wallet -- pocket money). Need something more ? Another fixed tranche of 0.100 BTC, toward the same address. Just that. A perfect tweak. Of course, the X address might be stored in a hardware wallet, fully secure. Other kinds of spending might be made possible only using the server itself (as to unlock the full control over the address balance).
