No, this is not possible. Many people have made various attempts to hide or otherwise disguise Git's index aka cache aka staging area, and they all fail for one simple reason: Git actually makes new commits from whatever is in the index / staging-area.
This has several consequences, some of which are immediately all up in your grill and some of which hit you later, including these:
The contents of your work-tree do not matter to Git, except as a place to go to get files to store into the index. You can mostly, but not entirely, work around this using git commit -a which has an effect that is very similar to running git add -u just before running git commit.
A file is tracked if and only if it is present in the index. Tracked, untracked, and untracked-and-ignored status of files is literally impossible to explain without making note of the existence of the index, even if you otherwise mostly work around it using git commit -a.
The git status command runs two comparisons: one from HEAD commit to the index, and one from the index to the work-tree. The only way to explain its output is to acknowledge the presence of the index.
Eventually, if one chooses to do it, it's the index that stores partial changes using git add -p and the other patch-oriented operations (checkout -p and reset -p). Of course you can simply avoid these entirely; then you never see this aspect of the index.
During a merge operation—a merge-as-a-verb, as I like to call it—that runs into a conflict, the conflicted state is recorded in the index. Git puts all three copies of the file-that-has-conflicts into the index. Each file in the index actually has four staging slots. At this point, the base version goes in slot 1, the HEAD or local or --ours version goes in slot 2, and the remote or other or --theirs version goes into slot 3. Resolving the conflict really means doing your own merge work, then copying the result into the normal staging-slot zero, wiping away the three higher-numbered staging entries.
Mercurial, which is otherwise very similar to Git, has no index / staging-area. This proves that the concept is possible. However, the way Mercurial achieves this is that it treats the work-tree as the proposed new commit, rather than having a separate index object that is the proposed new commit. Mercurial then has a second separate object called the manifest that determines which files are tracked. Merge state during conflicts is stored in a third location (the dircache). In one way this actually winds up being even more complicated, though it makes the usual case of working with Mercurial much simpler and more user-friendly.
To make Git work like Mercurial here, you would need to wrap every Git operation: hide the entire user interface and implementation from users, with some auxiliary state to keep track of why the index state is the way it is. Essentially, you would need to create your own manifest and dircache to remember which files to copy in and out of the index so as to make things look as though the work-tree were the proposed commit. You would need your own status wrapper, and you might even want to run in detached HEAD mode all the time (I have not thought enough about corner cases and, e.g., hg histedit equivalence here).
