-collecting resources
To collect a certain ressource, you would simply click on the resource in the city view, a window would pop up letting you increase or decrease the amount of people working in that square. increasing pop in that square takes pop from the idle column and move them to the resource. Decreasing would transfer people from the resource to the idle column. The more people working a tile, the more of that resource would be stored each turn.

-building city improvements
To build a new city improvement, you would click on an empty square in the city view and select the city improvement and the amount of people to want to build it. The amount of people would be taken from the idle column and begin constucting the improvement (or wonder). You could have build queues: click a second time, third time etc on an empty square and set a city improvement but assign nobody to work there. After completing the first city improvement, the workers there would automatically move to the next build order.
Unlike, the current civ city model, this model would allow you to build several improvements simultaneously. Click an empty square, pick improvement, assign workers, click a second square, pick improvement, assign workers, repeat as many time as you want (as long as you have enough workers) and each improvement would be constructed simultaneously. If one improvement were finished before the other, the workers would add to the next improvement being built. If that was the only build order, the workers would go to the idle column and the player would be prompted about it.

-working city improvements
Once city improvements are built, you would assign people to work in them, by clicking on the city improvement in the city view and assigning people from the idle column. Naturally, the more people assign to a city improvement, the faster it would do what it does. For example, a research lab would make reseach go faster the more people assigned to it. Each city improvement would have a maximum limit of pop that can be assigned to it. So for example, if a research lab reached the maximum amount of people it can hold, you would neeed to build a second research lab to increase your research further.

-changing tasks
The idle column would be used to transfer pop from one task to another. It would be a two step process. First decrease pop from task that you want to reduce. The pop would go to the idle column. Then increase pop of task that you want to increase and the pop in the idle column would go to that task: You've transfered people from one task to another.

-resources
At the end of each turn, the amount of each resource (like food, ressources to build city improvement or weapons,energy etc) that the city is consuming would be automatically deduced from the resources stockpiled. Note: the energy model could be implemented. Energy would be a resource that would have to be produced. Improvements like the nuclear plant would produce energy for example. Some improvements would need enegy to function.

-Happiness
Happiness would work on a group by group level. ie, the group assigned to produce food would have its own happiness level, the group working in research lab its own, etc...
So, instead of the current civ model where the entire city riots and shuts down, this model each group would riot or throw a "we love ..." individually. If the group producing food rioted, the city would cease producing food but the rest of the city would function normally. If a group reached a "we love..." day, it would do its taks faster. If things were allowed to get really bad, and several goups rioted then they might try to overthrow the city and become independant. So it would be gradual. (Interesting note: you would not want the group that is your army to riot!)

With the proper micromanagement help (I mentionned a few), this model would not be too hard to manage.

This model also implements a lot of other ideas (recruitment, energy model, simultaneous build orders etc) that people have suggested into one model.

Any questions? Comments? Please, don't hesitate.

One more thing.. Nukes and other weapons of mass destruction could kill off real numbers now..

I'm not sure how these real number would be incorporated in military units though.. Any ideas?

Of course in real life an army doesn't know exactly who they are fighting against and how many. But at the very least they have some idea as to how many troops are over the hill, even if it is simply counting the number of fires during the night. I do not want to start an attack if I have no idea who I am fighting.

In terms of detecting how many enemy troops there are. Here is one way of handling it: terrain, distance and number of troops would determine if the enemy is visible to you or not.
-terrain: is the terrain easy to hide in? for example, forests would mask an army better than plains.
-distance: the enemy has to be within range for you to detect it. You could build towers (and later in the game, satellites) to keep a coverage of you empire.
- number of troops: it is harder to hide a large number of troops than a small number of troops. The smaller the number of troops the easier they can hide.

With all these factors compiled, the computer would determine the visibility of a unit. if an enemy army were visible, you'd be able to click on them to find out their composition (how many are there). I think here, there is a need to simplify: if a unit is visible, you would always get accurate info on the enemy unit. Imagine thinking a unit is made up of 500 infantry and then when they attack, losing badly because there actually was 12,000 infantry. Uncertainty in the number of enemy troops would make the game too unfair.

Example : You have a 4 pop city (100000 person). Build a settler (3 pop, 60000 persons)
Use the settler to start a new town and your empire will only have 70000 (1pop -10000 + 3pop -60000)habitants instead of 100000 - Where are all the others?