Q:

Estimating user stories at the start of the project so that the PM can determine a quote for the client

Recently I have started to work on a team in a new project. Our company is attempting to run things in an Agile manner.
The project team consists of 4 developers each from different teams and with different business domain knowledge of the new project.
Our first get together involved going through a list of user stories and using Planning poker attempted to give estimates for the stories presented. However I really struggled with this process.
Here for a few things that I struggled with.

A-lot of the stories were UI driven and the complexity of it could depend on the complexity of the UI which we had no idea of. Hence I struggled to estimate appropriately.
The PM wanted us to estimate all the stories. However some of the stories had huge unknowns and questions which the PM couldn't answer.
Some of the stories involved knowledge about how we were going to implement the system from a code design point of view. We couldn't really agree on anything in particular as it involved some decisions from external people.
In our estimates there was no tester involved to add their input.

An example of a couple of the user stories looked like:

As an Account Manager / Field Office I want to to install the
application locally so that I can use it when offline.
As a CRM Administrator I want to be able to store the xml files from
the application into  the company CRM system  so that I can print
branded reports.

Despite all of this, we still went through estimating using relative story points.  The PM was then going to go away and cost up the project and estimate it time wise so she can do a quote for the company requiring the work.
My questions include:

As developers is it our responsibility to ensure we have enough information in order to estimate.  If we have unanswered questions should we push back and require more.
Should you estimate all user stories at the start of a project?
Given our estimates what is the best way for the PM to determine the hours per point so that she can estimate a total cost?  I believe typically we use the average time from a previous project however this project consists of 4 new developers.
Should we do UI mockups and design discussions during this process to help us better estimate?

A:

If project is new and there is no previous experience then I suggest you use story points to estimate user stories.

A-lot of the stories were UI driven and the complexity of it could
  depend on the complexity of the UI which we had no idea of. Hence I
  struggled to estimate appropriately.

If complexity depends on UI then usage of story points is the best choice. Relative estimations is not as fragile as absolute ones.

The PM wanted us to estimate all the stories. However some of the
  stories had huge unknowns and questions which the PM couldn't answer.

For that stories you can either ask for clarifications or give raw estimations/guesstimate. It is up to you. If stories are really huge and not clear I suggest you ask PO to split them and participate your estimation meeting. I'm sure you'll get the fastest feedback then.

Should you estimate all user stories at the start of a project?

Estimated backlog is required for efficient product backlog management by Product Owner. It is a good practice to fill in and estimate the whole backlog when project starts in order to provide a high level estimation of the product. It is obvious that new stories will be added in the future anyway but it can provide a starting point.

Given our estimates what is the best way for the PM to determine the
  hours per point so that she can estimate a total cost? I believe
  typically we use the average time from a previous project however this
  project consists of 4 new developers.

Yes, experience from previous projects can be used. You can calculate an average amount of story-points per developer per sprint. Anyway, it is better to calculate an actual team's velocity after 2-3 sprints since "Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known."

Should we do UI mockups and design discussions during this process to
  help us better estimate?

If development team consider that UI mockups are needed for their development then there are no reasons to avoid them. 

In our estimates there was no tester involved to add their input.

If you follow Scrum/Agile then there is no value in the increment without testing since it is a part of Software Development process. Every story requires acceptance testing. After several sprints you'll define the team's velocity - how many story points your team can finish within one sprint.

