Sprint Zero / Sprint 0 task

Although the need for inception activities is important, I would recommend making that inception period contain as little as possible so the team can quickly turn to delivering useful increments and getting feedback. Consider the lean principle of deciding as late as possible - deferring decisions and keeping options open for as long as possible can reduce waste and lead to better decisions. By focusing on delivery and getting feedback, you may find that some identified work becomes invalidated or unnecessary. This applies to all decisions, from what goes into the backlog to how much design to do to how much setup to do.

Making decisions about if and how to estimate would be one of the things that does make sense to do in an inception period. I would argue against estimation at all. Instead, focus on decomposing the units of work into the smallest size that can be delivered and used to get feedback. Using actual data, like cycle time and throughput, can help you begin to forecast the completion of work within a couple of Sprints.

In Scrum there is no excuse for putting empiricism in delay, and a team should expect technical infrastructure and architecture to emerge along with everything else.

Most of the work undertaken in early sprints can be setup work, as long as some usable functionality -- however small it might be -- is used to seed the empirical feedback loop. A smart team might choose the feature functionality it provides to validate these technical underpinnings to prove they work, thereby reassuring the Product Owner that the corresponding investment is not wasted. This technique is sometimes referred to as a tracer bullet or finding the red thread through the system. The emphasis in future Sprints can gradually shift to more valuable functionality, all the while building on an increasingly firm technical foundation.

The vocabulary we use gives transparency over what we mean. If an organization is bent on having a setup phase of some kind, the best thing you can do is to call it that. Don't spray a go-faster stripe on it by pretending it is a Sprint, not even "Sprint Zero". Accept that you are putting empirical feedback in delay and must wait until the end of that phase, plus one Sprint, before you obtain it, and deal with that reality.

Agree with everything @Ian and @Thomas have shared.

Some other points to consider...

It has been my experience that there tends to be a lot of build up or expectations put around executing Sprints. We feel the need to try to get everything set up nicely before we start, but in reality, we have already started when we initiate that set up work. We just haven't committed ourselves to the feedback loop that comes with a Sprint. We postpone transparency, inspection, adaptation with our Stakeholders until we are producing shippable, presentable value. There is also value in our initial work as it enables the product to be built in the first place.

"Sprint" is a defined thing. They are the heartbeat event that sets the cadence for the other Scrum Events, and all work necessary to work towards the Product Goal happens within it. They are fixed length for consistency. A new one immediately follows the previous one. And so on... Suffixing Sprint  with Zero, doesn't change the intended purpose of a Sprint. 

What prevents you from sprinting now?

If you start small and work incrementally, the work you mentioned could be done within Sprints. Solutions, architectures, technical set up etc. could be done in Sprints and emerge over time and through increments. These are all enabling steps towards your Product Goal. Your Definition of Done can evolve as you go.

Will it be messy? Most likely yes and that is to be expected.

If you plan on using the nomenclature of numbering your Sprints, then Sprint 0 would be the first sprint. (i.e. 0,1,2,3,4,.......99,100....).  So why should it be any different than Sprint 1? 

Everything said above says most of what I would have said.  In my experience, organizations have more success with Scrum if they spend a day or two putting together and refining a few Product Backlog Items and then start their first Sprint.  Will the first one be perfect.  Absolutely not.  But it starts the empirical process of learning.  Do something, inspect the outcome, adapt if necessary.  Even if you team is made up of individuals that have worked within the Scrum framework before, there will be need to discover how to work together in the current domain. 

Sprint 0 is your first Sprint.  Treat that way and learn. 

1.Should we have a completed Data model in place to start sprint 1? (or) Can it be evolving in sprints like assigning user story to Data modeler in each sprints?

To start a Sprint you need the product log with user stories, otherwise you cnat start it

Prior to the first Sprint of any Scrum project you need to Identify Project vision, business goal, prioritize user cases, manage epics and user stories, and only after that you can start a sprint

User stories can be added to the backlog through the project, is not a fixed document

Source of actual user stories depends on the nature of each project

2.Can we complete technical setup / global configuration for ETL development during sprint zero/Initial phase?

Yes, if this is a a part of the project vision(roadmap) you have created with your team.

3.Initial backlog sizing can be done with T Shirt sizing or Story point method?

Anyway the team will decide, but for unexperienced team its unadvisable to use story points. Best advice would be to start with time related measurement, like ideal days, then move to t shirt sizes, and then teach team to translate t shirt sizes into story points using Fibonacci sequence

4.QA setup can be done in sprint zero/Initial phase?

As it was pointed out, there is no such thing as 0 sprint, every first Sprint of teh project is Sprint One

If team will decide to move the tasks related to QA setup into sprint backlog, then answer is yes

Please remember that it Scrum team as whole, not just PO or SM who moves and prioritizes user stories from product backlog into sprint backlog

Can this decision cause the failure, because QA setup can be done in sprint zero/Initial phase sounds like a epic which young Scrum team may not be able to digest? So  DoD will not be met, and PO will refuse to accept the product in the end of the sprint

Its possible, and this is part of Agile process of empirical learning and reducing risks

The money invested by organization in the first sprint can be considered investment into training, and team will learn picking the tasks more accurately