This sounds like you are searching for a single answer to many different questions.
The time it takes maintenance to run can be addressed. How are you re-indexing? When is the reindex triggered? Is is done when needed, or blindly done on a schedule? What causes the fragmentation? Have steps been taken to prevent fragmentation, thereby removing the need to reindex? Finally, maybe stop reindexing. It may not make any sense.
If there are locking and blocking issues on this large table, then the answer is likely not going to be partitioning, breaking it apart into thousands of smaller tables, or any number of other ideas. This is a separate issue, and should be addressed as such.
Slow retrieval of data is also a separate issue. What specifically is the issue, and what has been done to alleviate that? Have you attempted to tune the queries? Are you indexes correct? Do statistics need to be updated more frequently? Some possible thoughts, suggestions, and additional questions include:
Pre-aggragation of data. Has this method been considered?
Do all of the selects need to be on real time data? Can you offload some of the workload to different tables that are populated by an ETL?
Can the application be re-written to reduce the number of calls to the DB and the amount of data being retrieved from it? Has caching been explored?
Here's an example. In one of our systems, there is a proc that was being called hundreds of times a minute. It returns a single code. For each session (user/client), the value does not change. It actually only needed to be retrieved once. The original developers were using the call to the procedure like a global variable. The proc ran in a few milliseconds; it used the clustered key and read one row to get the value. But the fact that this was called millions of times an hour caused stress on the system. Once the dev's changed the code to stop doing this, the DB servers were a lot happier. The original thought was to add more RAM and CPU to fix the performance issues. The moral here is that unless you have completed some in-depth analysis of the causes, and break these causes apart, your initial idea is going to move the problems from one place to another.
You asked a simple questions, what do we think about creating thousands of separate tables to fix this. The response is going to be equally simple. We think it's a bad idea. Without a more in-depth analysis, getting any ideas that may solve your issues is likely not possible.