I know from personal experience that even slight differences in creative vision can easily tear a team of volunteers apart. In more professional development teams there is usually a lead designer who has the final say on all creative decisions, but when neither of you is paying the other for their work, it is hard to agree on who of you that is supposed to be. If you want to work in a relation where you both see eye to eye, it is important that you make sure you both are on the same page.
First of all, it is helpful to agree on the style of gameplay, narration and atmosphere as closely as possible before even the first bit of work is done. Otherwise you risk that both of you feel the need to defend the work you have already done and are less able to make compromises. During this meeting you might realize that you two actually have vastly different creative visions and in fact want to make two completely different games. That means that unless one of you volunteers to take the creative backseat and make the game the other person wants to make, it might not be a good idea to work together.
But remember that game design is an incremental process. After a while you might realize that neither of you really likes the directions you initially agreed to anymore. In that case you can agree on changing the direction, but it is important that you make that decision together.
Another important technique to avoid unconstructive power struggles is a clear separation of responsibilities and creative control. Go through all the aspects mentioned in the question and decide who of you is in control of each. The other person is of course encouraged to give feedback. But that feedback should usually be more substantial than just personal preference and backed up by objective arguments. The only subjective argument you might want to allow is "this doesn't work well together with [thing I am responsible for]", because with such a separation of powers it is easy to create an inconsistent work.
But most of all, remember that this is your first game. You both are still learning. It is OK when it is not perfect. You should concentrate on making a playable product. Do not let misguided perfectionism get in the way of that. Yes, your first game will probably suck. But that's OK. Too many projects died because the developers just couldn't settle for a "good enough" solution but lacked the skills and resources to deliver the "perfect" solution they envisioned. Creating stuff that sucks and then reflecting on why it sucks is the first step on the road to creating greatness.