After a the components are added in the package and it is uploaded as the beta package, testers can install it in their org. What if the bugs come up? Can we make changes in the package again to resolve them?
Yes, but beta packages cannot be upgraded, so the beta testers will have to uninstall and reinstall the package to get the newer version. I recommend using sandboxes with beta packages so you can simply request a new sandbox and reinstall instead of uninstalling and reinstalling (which can take quite a bit more time if there are many manual steps involved). You shouldn't generally install beta packages into production environments.
After everything is ready and the package is uploaded as Managed released, how can we resolve bugs or upgrade the package later?
Managed packages can be upgraded. Simply fix the bugs, and provide your clients with the new installer link. When they use it, if an earlier version is installed, they will be prompted to upgrade to the newer version instead of installing anew. There's no special steps you need to take to make packages work like this, as it is part of the platform. You can also set an InstallHandler hook to migrate data or configure new features that were not part of the prior package if you desire.
During package creation, namespace is prefixed before the components. So does this means all the soql, sosl and reference to VF page names will fail? For example, when we reference Page.PageName in pagereference methods?
No. Your queries and page references will operate in the scope of your namespace. This means that all SOQL/SOSL queries will attempt to use your namespace, even if there are objects, fields, classes, and so on in their package from a different namespace or that are native to the client's own organization (e.g. things they have created that do not belong to a package). You don't generally need to prefix your code with the namespace, which makes it easier to have each developer work in a separate, non-namespaced developer edition, and migrate the code to your managed package developer edition with minimal fuss.
Should we have two different org, one for development and another for packaging? Or some other approach?
This is a matter of preference, but I would generally state that each developer should work in their own isolated developer edition, and migrate changes to the managed package organization separately. This can help reduce disasters that can occur from directly operating on the primary package's code. I would also strongly recommend a Git or Subversion repository so that you can roll back undesirable changes if you need to, and prevent developers from overwriting each other's work. If you use this approach, require developers to check code into the CVS system before they can deploy the code to the packaging organization.
Anything to take care when multiple developers are working to develop a managed package? Any tips?
Use a CVS, as mentioned before, and keep each developer in their own isolated developer edition. Consider setting up a continuous integration system, like Jenkins, to migrate committed changes to the packaged organization, and I'd also recommend that developers avoid making any changes in the packaged organization directly (use the continuous integration system to deploy these changes). It's easy for multiple developers working in the same organization to overwrite each others' changes, and you want to avoid this as much as possible. Sometimes simply communicating with each other is sufficient, but a CVS makes it much less likely that you'll do permanent damage to someone else's code.
Anything important that you can think of while developing a managed package?
The most important piece of advise is this: plan your metadata carefully, especially those classes that will be "global", ahead of time. Once packaged and uploaded to a managed package, you can't generally change their data types or delete them. Global APIs become "cooked" in, so they can be deprecated, but not removed entirely. Avoid poor naming conventions and parameters in these classes, because customers can see their contents. Of course, requirements can, and do, change, so sometimes you can't avoid this, but destructive changes should be kept to a minimum.