Let $b$ be the bit width of the input and output of $E^{(1)}$ and $E^{(2)}$. For the block cipher DES that would be $b=64$, with $n=56$. In the first section of this answer I'll assume $n+4<b<2n-4$, which holds in this case and simplifies some approximations.

I'm assuming the function iterated has $b$-bit result (not $n+1$ as in the question), so that any collision found with a usable discriminator bit ensures that $c=E^{(2)}_{K_2}(E^{(1)}_{K_1}(p))$ where $K_1$ and $K_2$ are derived from the colliding inputs, and the common output is $E^{(1)}_{K_1}(p)=D^{(2)}_{K_2}(c)$. This particular $(K_1,K_2)$ has odds about $2^{b-2n}=2^{-48}$ to be the correct one, and that's checked with negligible cost, just as in the normal MitM.

I see no reason why the proposed method would not find collision with a usable discriminator bit as expected for a random function, at an expected cost of about $2^{b/2+1}$ evaluations of the function (only a little more with cycle-finding using distinguished points; I neglect that). So the expected cost is like $2^{2n-b/2+1}=2^{81}$.

Using little RAM comes at the price of making about $2^{n-b/2+1}=2^{25}$ more evaluations of $E^{(1)}$ or $E^{(2)}$ (I have silently dropped small factors here and there, but hope this holds within a factor of $2$ except for the cycle-finding overhead). It's hard to tell if, and when, this might be preferable in practice to the most obvious time-memory tradeoff for MitM, where we split the problem into (at most) $2^r$ runs each using a manageable table of $2^{n-r}$ entries, for an expected cost dominated by $2^{r+n-1}$ evaluations of $E^{(2)}$ and search of that in the table.

---
The above calculation suggests to increase $b$ (the width of the center state in the cipher, also the width of the function we search collisions for) up to something closer to $2n$ (beware that the above cost calculations become invalid when approaching $2n$, and that when $b$ is not a multiple of the native block size we are not sure that the candidate $(K_1,K_2)$ found by collision really works for the $p$ and $c$ blocks we used).

With that change, the proposed method seems to be what's studied in the [section on MitM][1] in Paul C. van Oorschot and Michael J. Wiener: _Parallel Collision Search with Cryptanalytic Applications_ (in [Journal of Cryptology, January 1999, Volume 12, Issue 1][2]), which I think supersedes their earlier [_Improving Implementable Meet-in-the-Middle Attacks by Orders of Magnitude_][3] (in proceedings of Crypto 1996).

  [1]: http://people.scs.carleton.ca/~paulv/papers/JoC97.pdf#page=16
  [2]: http://link.springer.com/article/10.1007/PL00003816
  [3]: http://link.springer.com/chapter/10.1007/3-540-68697-5_18