Mathematically, no, there is no difference.

However, if you're playing a card game that requires deck manipulation, you will of course want to generate the whole deck at once, because you might need to perform actions like placing a card from your hand on the bottom of the deck. You can't do that if the rest of the deck doesn't exist yet.

If you're generating cards at draw time, it can get expensive to check to see if a card has been generated yet, because you'll have to check the table, everyone's hand, and the discard pile. Or maintain a separate list of all cards generated so far, but at that point you might as well have just generated a whole deck in the first place.

Assuming I'm understanding your thought experiment correctly, AFAIK, unless the chance of a duplicate card coming up is an issue, it should be about the same.

QI did a bit about this:

The chances that anyone has ever shuffled a pack of cards in the same way twice in the history of the world are infinitesimally small, statistically speaking. The number of possible permutations of 52 cards is '52 factorial' otherwise known as 52! or 52 shriek. This is 52 times 51 times 50 . . . all the way down to one. Here's what that looks like: 80,658,175,170,943,878,571,660,636,856,403,766,975,289,505,440,883,277,824,000,000,000,000.

To give you an idea of how many that is, here is how long it would take to go through every possible permutation of cards. If every star in our galaxy had a trillion planets, each with a trillion people living on them, and each of these people has a trillion packs of cards and somehow they manage to make unique shuffles 1,000 times per second, and they'd been doing that since the Big Bang, they'd only just now be starting to repeat shuffles.

https://www.youtube.com/watch?v=SLIvwtIuC3Y

No. Either way, you have the same set to pull from and your only pulling one card. The only difference is that generating a card means you don't have a set order when the first one is pulled.

If you wanted an equivalent with physical cards you'd pull a card, shuffle the rest, pull another card, repeat until the deck runs out.

Well, a little bit of 'yes' and a little bit of 'no'.

If it is possible over the course of the game for turn orders to be changed, or for a player to choose to draw a card, or cause another player to draw a card, then it matters in a way.

If I can cause actions to make another player draw a card, then it is more meaningful if the deck is shuffled already, because the card that I caused the player to draw is the same as the card I would have drawn if I drawn a card instead. However, from the perspective of the user, there is no way for them to know the difference.

I feel like it is better for the integrity of the game if the deck is shuffled for real, though. Because if ever a user finds out that it doesn't work how it is expected, then it cheapens the experience in a way. Kind of like how the old Mario Party games determined the outcome of dice rolls when the die appeared on screen instead of when you pressed the button to 'roll' them.

I mean, you can get the same sequence of cards, as long as your mechanism used to select a card in #1 is the same as in #2. It's just like doing #2 52 times in advance and then recording the results.

There are certain reasons that you might want to do #1 that don't relate to the sequence of cards coming up. There are certain problems involving multiple untrusted parties where it can be advantageous to be able to prove that you have not fiddled with the card order after the initial "deal"; one way to do this is to generate and then transmit an encrypted list of cards, then later send the decryption keys.

https://en.wikipedia.org/wiki/Mental_poker

Mental poker is the common name for a set of cryptographic problems that concerns playing a fair game over distance without the need for a trusted third party. The term is also applied to the theories surrounding these problems and their possible solutions. The name comes from the card game poker which is one of the games to which this kind of problem applies. Similar problems described as two party games are Blum's flipping a coin over a distance, Yao's Millionaires' Problem, and Rabin's oblivious transfer.

The problem can be described thus: "How can one allow only authorized actors to have access to certain information while not using a trusted arbiter?" (Eliminating the trusted third-party avoids the problem of trying to determine whether the third party can be trusted or not, and may also reduce the resources required.)

An algorithm for shuffling cards using commutative encryption would be as follows:

1. Alice and Bob agree on a certain "deck" of cards. In practice, this means they agree on a set of numbers or other data such that each element of the set represents a card.
2. Alice picks an encryption key A and uses this to encrypt each card of the deck.
3. Alice shuffles the cards.
4. Alice passes the encrypted and shuffled deck to Bob. With the encryption in place, Bob cannot know which card is which.
5. Bob picks an encryption key B and uses this to encrypt each card of the encrypted and shuffled deck.
6. Bob shuffles the deck.
7. Bob passes the double encrypted and shuffled deck back to Alice.
8. Alice decrypts each card using her key A. This still leaves Bob's encryption in place though so she cannot know which card is which.
9. Alice picks one encryption key for each card (A1, A2, etc.) and encrypts them individually.
10. Alice passes the deck to Bob.
11. Bob decrypts each card using his key B. This still leaves Alice's individual encryption in place though so he cannot know which card is which.
12. Bob picks one encryption key for each card (B1, B2, etc.) and encrypts them individually.
13. Bob passes the deck back to Alice.
14. Alice publishes the deck for everyone playing (in this case only Alice and Bob, see below on expansion though).

The deck is now shuffled.

... you do a random select each time.

Is that even possible? I know that computers are not able to make true randomness, and that people are even worse at it. There's that lava lamp wall that somebody uses, maybe?

Yeah, #2 is both more space efficient and more time efficient.

How I'd generally do something like that:

1. Create an empty linked list.
2. Generate a random integer between 0 and 51 inclusive.
3. Iterate over the linked list and increment the random integer by one for each integer in the linked list less than or equal to your newly-generated random integer. You can break out of that loop as soon as you hit the first integer in the linked list greater than the newly-generated integer.
4. Binary insert that integer into the sorted linked list.
5. For the denomination, output the newly-generated integer modulus 13 plus one. Translate 1 to ace, 11 to jack, etc.
6. For the suit, output floor of the newly-generated integer divided by 4 plus one. (Translate zero to "hearts", one to "diamonds", etc.)
7. Loop back to step 2 51 more times.

Step 3 can definitely be optimized much more with a B-tree and a little thought. If you want jokers included, it's pretty straightforward. (Just change step 2 to generate a random integer between 0 and 53 and tweak steps 5, 6, and 7.)