Clearly $\ell_n$ will be large (in the 1000's), but from my understanding the reason RSA-moduli have to be so large has to do with factorization algorithms, not hardness of DL.
Actually, it's pretty much the same for your algorithm - computing the discrete log is essentially equivalent to factoring the modulus; hence following the standard factoring recommendations for $\ell_n$ is appropriate.
For the factoring -> discrete log step: the best known algorithms for factoring and computing discrete logs have roughly the same complexity given the same sized input. Hence, one strategy an attacker might try is factoring the modulus, and then computing the discrete log modulo each prime (and then combining the results). The cost of the latter steps are much less than the cost of the factoring step; hence if your modulus is small enough to factor, it is small enough to compute the discrete log.
For the discrete log -> factoring step: if someone is able to compute the discrete log of an arbitrary value modulo your composite, they can factor the composite. One simple way would be to select a value $x > n$, and compute $z = g^x \bmod n$, and use your method to compute the discrete log of $z$, that is, the value $y$ s.t. $z = g^y \bmod n$. Because the order of the $n$ is less than $x$, we have $y < x$, and hence $x-y$ is a multiple of $(p-1)(q-1)$; deducing the factorization from that is trivial.
What is a reasonable choice for $\ell_\Lambda$
Well, the advice isn't quite as clear there.
The lower bound I know about: the generic discrete log methods (such as giant-step-baby-step) apply, and so we must have $\ell_\Lambda \ge 2 \cdot seclevel$ where the target required complexity is $O(2^{seclevel})$.
The upper bound: well, if you look at the above 'discrete log -> factorization' argument, you see that this would apply (assuming $p, q$ are the same bitlength) with $\ell_{\Lambda} = \ell_n / 2$, that is, you could factor such an $n$ given an oracle that can compute a discrete log with $\ell_{\Lambda} = \ell_n/2$; hence taking that as an upper bound seems safe.
That still leaves the open question: where in that range is the appropriate $\ell_{\Lambda}$? I do not know if any discrete log methods that would be able to take advantage of a $\ell_\Lambda > 2 \cdot seclevel$ and which would be cheaper to perform than a general discrete log.
Hence, $\ell_\Lambda = 2 \cdot seclevel$ may be sufficient; on the other hand, if increasing $\ell_\Lambda$ is cheap, I'd do so...
