Agile Scrum – Should a Scrum Team Member or Scrum Master Be Appointed as Product Owner?

In general, the role of the PO during a sprint should be passive, i.e. provide feedback when asked for it, but not micromanage the work of the team. Any changes that result from such feedback have to be weighed against other priorities. But ultimately, the PO represents those paying for the project and thus calls the shots. As for your specific questions:

1. If the PO has detailed expectations about the design, these should be provided as a branding / CI guide before development starts. Demanding lots of detail changes only after seeing the UI in development is not ideal, but if the PO feels these changes are very important and is willing to accept the consequences, i.e. features dropped out of an iteration because people had to implement the desired changes instead, that's OK too.
2. Choosing specific elements of the architecture is certainly the domain of the PO, but very much something that should be done before development starts. Fundamental changes later on will cause massive delays (it's pretty much guaranteed you'll have to abort the current Sprint and use at least the next one mainly to implement those changes). Again, if the PO accepts the consequences, it's his decision. If no, it starts to look like the project lacks the main foundation of Scrum: the assumption that everyone is working on a common goal and making rational decisions on how to best get there.
3. Again, it's ultimately the PO's decision, and this kind of thing is perfectly OK to discuss with the PO if there are open questions, since he may have domain knowledge your analysts don't have. But if he insists on doing things differently than those who have studied the problem recommend, and without providing a rationale, then that also strongly hints at someone not well fit for the job.
4. Whether to implement something as a wizard or a single complex page is a very good example for something the team could ask the PO to make a decision on. But having him give constant feedback on details is not efficient. Basically the idea is to have the team implement a complete usecase and only occasionally get feedback on things they are not sure about or when they have completed a significant piece of work. To get back to your example: after getting the PO's decision, the Team might create a GUI mock-up for the complete wizard or page, show that to the PO to get feedback, change one or two things and implement it, then show the complete implementation in the sprint review.

Experts in Scrum are very firm in stating that the Product Owner and Scrum Master should be two different people. However, there is no such rule excluding either from the Development Team. Note in the Scrum Guide:

Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

The corollary to that last line would be that, if the Product Owner is executing the work of the Sprint Backlog, he or she is counted as a member of the Development Team.

That said, do whatever works to get your work done well.