For our school project we had to make a game in "14 days" (this is in quotes because we also spent time outside project days on it. All in all probably 20 days).

For this we used Ogre3D, this is not actually a game engine, so things like physics (Nvidia PhysX) and audio (FMOD) and such were all implemented by ourself. Our team consisted of 4 programmers (including myself as a tech lead), 1 designer, 1 project team lead and something along 10 artists or so whose tasks ranged from audio to modeling, to texturing and whatnot.

Here's the full playthrough by one of the programmers (who know where to go mostly). Hope it helps!

[media][/media]

- engine used

Own engine.

- game (if you can provide a link to see how more complex it is compared to what we want to do)

[media][/media]

- the time it took to get a beta version

Not in beta yet, but almost alpha. Engine+Game took more than 12 years sofar

- size of the team?

~1 (+part sparetime artist for the last years)

Concluse: hmmm... use some existing engine if you want to make faster progress

As soon as there is competence overlap then there are going to be ego problems such as will we use my solution or yours or if my solution is always discarded because it's inferior I'd feel I'm no longer part of the team etc

This is one of the reasons good dev studios have lengthy, selective hiring processes and are always looking for good people: there are swarms of technically competent people out there, but only a small fraction of them can work well with others. I'm sure you're speaking hypothetically, but if your idea gets discarded, that doesn't mean you don't have something to do anyway (just a different implementation) and if you start to get defensive over sections of code...yea, not so good.
In all honesty, this situation isn't going to happen that often. You either have a tech/design lead, who makes most of the calls on design, or you're given your own black-box and i/o contract ("your module needs to accept a .jpg and spit out a heightmap with decent efficiency, internal implementation is up to you"), or it's a small team and there's enough work to go around already that people are just handed certain sections of the design and told to work with eachother on an agreed-upon interface between components. In any case, if the team communicates and agrees on why something is accepted vs thrown out, the "wounded ego" problem shouldn't occur because everyone got to voice their reasoning. You'd be surprised how far simply letting people explain their idea will go in getting them to buy in to the best solution. (This comes up in several Agile processes, too).

Edit: additionally, I'd much rather have competency overlap: if only one person knows how to do X, then only one implementation of X will ever be attempted. If 3 people know how to do X, you (hopefully) discover the best of three possible ways to do X, kind of a genetic algorithm that spits out the best code for your game.