There are certain design/architecture related decisions which you/your team would need to make based on your specific requirements weighing the pros/cons & constraints of each solution. These constraints/decisions are pre-requisite to drill down further on a particular solution and answer the questions that you currently have.
Here is an old link that explains about AMP pages in detail and provide options to host/configure:
In the above example, they have chosen to host the amp pages via a separate domain. You could follow the same solution, its probably the easiest path unless you have business/technical constraints. Alternatively, you could use the same existing domain (and use either same or different urls based on feasibility assessment) to host both AMP and non-AMP pages - if you choose the latter option, then, you would need to iron out the design for a lot of aspects including SEO/caching/content rendering/routing of mobile traffic to these AMP pages etc.
Whatever approach you take, you would need to design the end-to-end process flow for:
content storage //same page/node/url for both or different ones
different template/components // to inject AMP specific markup and strip out other irrelevant tags
content rendering and caching/flushing design to avoid content collision
routing design to route all mobile traffic to AMP specific pages (based on your existing infrastructure setup)
SEO strategy etc.
analytics strategy etc.
Coming back to AEM pieces, in my mind,
It would be better to use separate templates/components from best practices aspect
You may use content fragments/content services to serve content to both AMP and Non-AMP pages provided the markup that you use in those fragments supports both use cases.
so does that mean separate template components needs to be developed? -- preferably yes unless you want to tweak your existing components to support both use cases (make them generic) and just develop the new components to inject the AMP specific markup in the page
is it possible to do with single content or with same component? -- yes it could be possible based on the design approach you choose and your existing implementation. E.g. suppose that one of your existing component has just <ol><li> tags as markup which works well with AMP then the same component could be used for both AMP and non-AMP pages. Another component doesn't have a <link> tag required by AMP pages then its up to how you want to fix it - either create a new component or use conditional logic or inject it or something else
and how url will be configured? -- that depends on your design approach
do i have to provide separate url for mobile? -- that depends on your design approach
how can i make sure that AMP based page will not be visible in desktop search results and vise versa. -- search engines are smart enough to index it appropriately if you've configured proper tags based on AMP guidelines
do i have to make any firewall level changes for this? -- that depends on your design approach
To me, AMP pages can be considered as normal AEM pages with customized markup. Coming to your question, per my knowledge, there are a lot of pieces to it.
How do you plan to handle the non-AMP site/content/components along with AMP specific ones or is this use case only related to AMP site/pages? What are the design/business constraints that are already identified and could potentially impact the solution you pick?
Based on above answer, other follow up topics would be -
How do you plan to store and serve the content with this design? -- Yes, you could leverage content fragments for channel specific content which would reside under /content/dam. I'm not sure if you plan to integrate these fragments (or variations) with other channels/main site or just use content fragments as content services to some other app that would be responsible for the markup of AMP pages.
How do you plan to use analytics around it? - You may use Adobe Launch integration with AEM for AMP or a custom script for other tools
Do you plan to use responsive version of AMP or adaptive version of AMP with a possible separate mobile site/app?
Based on your design, you could either create global content fragments or AMP/channel specific fragments and render them as per use case.You might have to create specific template(s)/components to achieve the custom markup that is required by AMP pages. Just keep in mind that if you have any custom components already built-in for existing site that do not go along with content fragments design principles, then, you may to customize a ton of stuff. If you plan to share content with non AMP site as well then one of the solutions could be to use the selector based approach as mentioned in above link.